Hudson Brief Introduction

A About Continuous integration continuous integration (CI) is a practice designed to mitigate and stabilize the process of building software. Throughout the software development lifecycle, it is used primarily to ensure code quality, to ensure early problems (such as code defects), and to prevent problems from being discovered when the software development cycle becomes more complex.

(1) The role of CI mainly has the following aspects:

Software Building Automation: The CI process can be built on a pre-defined schedule, or on a specific event, for the target software. This build process is intended for all team members who develop the software;

? Build sustainable automated checks: The CI process can be set up to continuously execute new or modified checked-in source code, and when the software development team needs to periodically check for new or modified code, the CI system constantly confirms that the new code destroys the successful build of the original software. This reduces the overhead of developers checking for changes in their interdependent code;

? Build a sustainable automated test: an extension of the build check that ensures that when new or modified code does not cause a predetermined set of tests to fail after building the artifacts. As with build checks and tests, failure triggers a notification (EMAIL,RSS, and so on) to the relevant parties, informing them of a build or some test failure.

? Automation of post-build processes: Once automated inspection and test builds have been completed, a software component's build cycle may also require additional tasks such as generating documents, packaging software, deploying artifacts to a running environment, or a software repository. In this way, artifacts can be provided more quickly to the user.

(2) To achieve the above functions of CI, three components are required:

? An automated build process built with tools such as Ant or Maven. This is the most important aspect of a successful CI process, where the CI process often integrates the software, which needs to be done through construction. Both Ant and Maven are common build platforms that reliably automate tasks such as compiling, testing, and even performing software inspection and deployment.

? A code repository, such as CVS or Subversion. The CI server queries the source code management System (SCM) repository for code modifications. When a modification is found, the CI server performs a checkout (that is, updates the local sandbox) and executes the build. In addition to executing more frequently, the build process is the same as the build that executes in the on-premises environment.

? A CI server, such as Hudson, but cron jobs can also meet the needs. The CI server can automatically monitor the SCM repository and run the build when the modifications are detected. It should have the following basic elements: 1. CI server to be able to easily get the source code repository and internal source; 2. To be able to add build scripts and programs; 3. There is also a series of executable tests built around the component. The following figure is the basic structure of CI system

The various components of the system are functioning in the following order:
The developer examines the code that has been added and modified to the source code repository. (Source Code Updates in figure)
The CI server creates a separate workspace for each project. When a preset or a new build is requested, it will store the source code repository to the corresponding workspace, where the build is executed. (Project Workspace in the diagram)
The CI server executes the build process within the newly created or updated workspace. (Build in Figure)
Once the build is complete, the CI server selectively executes a previously defined set of tests in a new component. If the build fails, the responsible person will be notified by e-mail, instant message, or other means (failed). (pictured in reporting & notifications)
If the build succeeds, the artifact is packaged (the package in the diagram) and transferred to a deployment target (such as an application server) and/or stored as a new version in the repository (Figure Deploy/publish). This can be a part of a CI server, or an external repository, such as a file server or a valid URL for distribution like java.net and SourceForge. The source code warehouse and the component repository can be separated, in fact, it can take advantage of some no source code control system (CVS, SVN, CSS, and so on) CI server.
CI servers typically use some kind of console for project configuration and debugging, and initiate appropriate actions on request, such as building on the fly, generating reports, or retrieving some of the built-in artifacts. (figure in Server Console)

Two About Hudson

Hudson is a revolutionary open source CI server that draws many lessons from previous CI servers. One of the most appealing features of Hudson is that it's easy to configure: It's hard to find a CI server that's easier to set up, and it's hard to find a CI server with so much out-of-the-box features. The second reason Hudson is easy to use is that it has a powerful plug-in framework, so it's easy to add features. For example, a Hudson plug-in can track findbugs and code coverage over time. It can also report trends in test results (from JUnit or TestNG) as well as build results and corresponding execution times. It has been investigated that Hudson is currently the most used CI server.

The procedures for configuring Hudson using MAVEN and subversion are described below.

(1) Download and install and run Hudson

Download the Hudson War Pack (Hudson.war) in https://hudson.dev.java.net/[[BR]]

Run the Hudson server side with a jar with the command: Java–jar Hudson.war

You can also deploy it in a container such as Tomcat or JBoss, as described later in this method.

(2) After installing and running Hudson (deploy the WAR file to the servlet container or execute Java-jar hudson.war from the command line), Access http://localhost:8080/into the Hudson startup page as shown in the following figure: [[ BR]]

Before you create a new task, you can use System management to globally configure Hudson, such as the management plug-in to add, remove, disable, or enable various feature extensions for Hudson. The most important is the "system settings", where you can configure security, check "Enable security", configure the access rights of the Hudson server. By default, anonymous users can do all of the work. When this option is turned on, Hudson will use the account permission policy configured by the application server. Below you will also specify where MAVEN will be installed and where the JDK will be installed. "E-mail Notification" is an email notification, Hudson notifies the developer via mail of the occurrence of certain events, such as compilation failure/test failure/integration recovery, etc. Here you need to configure the SMTP server and the sender of the message. Click on "New Task" to select "Build a Free-style software project", which can be built with any SCM, arbitrary build system, etc. You can also build a Maven2 project with "Build a Maven2 project". "Copy First task" Creates a new build on the basis of duplicating existing work

Configuration Hudson as shown in the following figure

After you create a new project, configure it.

? Project Name: Item names

? Description: This is a free term that is used primarily to illustrate your description of the construction work. Not fill in.

? This build is parameterized: If you select this option, Hudson will allow you to provide an arbitrary set of key-value pair parameters that will be passed to the build process. The parameters that are configured are often the environment variables in the build run environment. (When you use the various automation of Hudson, it is sometimes required to provide a set of user input during the build process, using "parameterize" can be more convenient to build.) For example, you might set up an on-demand test where a user can submit a compressed file of a binary file for testing.

? Disable Build: If this is checked, the work will not be built until the option is disabled. (For example: you want to build every one hours, but find that the SVN server will be down in the next 24 hours.) When this option is set, there will be no new builds on this project. This allows you to disable the build process without changing external dependencies or submitting error notifications. )

? Advanced options:

Quiet Period: Here you can configure a static monitor that is actually already executing when the build is ready to run on a schedule.

Use custom workspace: By default, Hudson creates a workspace under ${jboss-home}/.hudson/jobs/[project name] (Note: Linux environment). This option will allow you to replace (it) with the specified address.

? Source Code Management: These are the three options by default:

o Subversion

o CVS

o None

The source of the project to obtain the way. Depending on the version control system used for the project, choose either CVS or SVN and fill in the repository URL. Here is an option to use update. To ensure that each build is not affected by the previous build result, the Use Update option is not recommended.

About None: If you install an SCM-related plug-in, select None, and restart Hudson, there will be some new options on this list.

Build Triggers: Sets the trigger for the build.

? Build after other projects is built: This option supports an assembly (flow-shop) line-Job dependency: The case that one job relies on the output of another job-- or in the following situations: you just want to simply put some of the relevant engineering constructs into a group to build together. When you select it, you will get a field, enter the name of the other project [multiple project names separated by commas], this build should be able to run.

? The Build periodically option supports custom task cycles similar to the crontab format.

? Poll SCM: This is a common option in CI systems. When you select this option, you can specify a timed job expression to define how often Hudson checks your source code warehouse for changes. If a change is found, the build is executed once. For example, filling in an expression with 0,15,30,45 * * * * will allow Hudson to check your repository changes every 15 minutes. For more information, please refer to the Quartz crontrigger for a detailed description of this timed job syntax. Build: Build script settings.

? Add Build Step: Click this button to add an instruction to execute the build script. Your instructions can be one of the following:

O Execute Shell

o Perform Windows batch processing

o Use Ant

O using Maven

Post-build Actions: The processing that needs to be done after the build is complete.

Archive The Artifacts: Package the results of the build and provide the download.

Publish junit Test Result report: Collects and publishes JUnit test reports.

? Build periodically: This option (also using a timed job expression) simply notifies Hudson to build the project at a specified frequency, regardless of whether the SCM has changed. This assignment belongs to me. The target test environment is periodically revised in some way and SCM is static. It might be helpful if you want to run some test cases in this job.

? Archive The Artifacts: Specifies a mask for files and directories that, when built, will be added to the Hudson Component repository, which is identified by the job (name) and build sequence number. All previously built artifacts can be selectively discarded to conserve disk space on the Hudson server.

? Record fingerprints of files to track usage: using a similar ant-like mask, Nen can instruct Hudson to generate the artifact's fingerprint code, make sure it is easier to find their location, and also determine if the components in the system are still in use.

? Publish Javadoc: If the build script can generate Javadoc, this option will instruct Hudson to publish the content and immediately publish it on the current working home page. Each successful build of the document content can be retained, but by default only the latest.

? Publish junit test Result report: If the build script performs JUnit tests, this option instructs Hudson to process the XML test document and produce a sustainable report for each successive build, processing the results based on the test rollup in progress. The result is a report on the current work home page, where the unit tests are displayed as old to new over time.

? Aggregate downstream test results: In some cases, a set of unit tests in a job can take much longer than the actual time it takes to build it. In these cases, you can choose to divide the build and test into different jobs so that the build can be done relatively quickly, and once one or more of the test jobs associated with it is executed, the build is completed successfully. When this option is selected, Hudson will count the results of the post-build job and can be traced back to their details. Used as the main basis for the success or failure of this build.

? Build other projects: compared to the previous option, this option is primarily used to implement a logical build and test process, which is divided into two or more two physical tasks and is executed sequentially. When this option is selected, you will get a field where you can enter additional job names that you want to execute after the current job [multiple jobs can be separated by commas]. [BR]]

? e-mail notification: When this option is selected, you can enter one or more e-mail addresses [multiple available spaces separated], and they will be notified when Hudson finishes executing the job. An Email will be generated when the event is triggered, including build failures, build instability, and so on. Here's an extra option, when Hudson decides to discard the build due to a user's error submission, a special message will be sent to the SCM submitter to let him check the source code

Once built, click "Generate Now" in the left column, and Hudson will automatically compile the code into an executable file.