Build a continuous integration environment using Hudson + Maven + SVN

Reproduced in: http://sinye.iteye.com/blog/572153

 

 

I. development tools used

1. Hudson: Hudson is a revolutionary open source CI server that has learned a lot from its previous CI servers. One of the most attractive features of Hudson is its ease of configuration: it is difficult to find a CI server that is easier to set, and it is also difficult to find a CI server with such rich out-of-the-box features. The second reason Hudson is easy to use is that it has a powerful plug-in framework, so it is easy to add features. For example, after adding the Tomcat plug-in, you can easily deploy the built war package to Tomcat. : Http://hudson-ci.org/

2. maven2: Maven is a top-level open-source Apache Software Foundation project. It was initially created to manage the complex building process of the Jakarta turbine project. Since then, both open-source development projects and private development projects have chosen Maven as the project construction system. : Http://maven.apache.org/download.html

3. subversion (SVN): Version Control Software. Tools similar to its functions include CVs and perforce. : Http://www.subversion.org.cn/

4. Automatic deployment plug-in for Hudson,: https://hudson.dev.java.net/files/documents/2402/106347/deploy.hpi

Ii. Tool installation and Setup

1. maven2 installation: unzip maven-2.0.4-bin.zip to D: \ maven-2.0.4 (or the location where you want to unzip, I configured it) below is the configuration environment variable, this is the same as that of version 1.0. (1) maven_home: D: \ maven-2.0.4 (2) Add % maven_home % \ bin in Path

In this way, the configuration is OK. To test whether the installation is successful, enter MVN-V in the command line. The following interface is displayed, indicating that the installation is successful.

 

 

 

2. install Hudson: There are two ways to install Hudson: (1) You can deploy Hudson to Tomcat and run the downloaded Hudson. put war directly under Tomcat's webapp, and start Tomcat.

(2) run the command to start Hudson. Step: first download Hudson. war, and then you can create a folder under a drive letter, such as D: \ Hudson (you can create a folder at will ), set the environment variable in this path (not to mention that you will not set the environment variable), hudson_home = D: \ Hudson, and finally use the Java-jar Hudson command. war starts Hudson

3. SVN installation: SVN installation is relatively simple. After downloading the installation file, you can download the installation file one by one.

Iii. Integration of maven2 + Hudson + SVN

This is important. The combination of the three methods is mainly for configuration here, while the configuration of maven2 and SVN is dependent on Hudson, so we will focus on the configuration of Hudson.

1. Configure Hudson

After Hudson is installed using the preceding Hudson installation method, the Hudson page can be opened through the http: // localhost: 8080/Hudson browser, as shown below (if you have already built a project, it will show the successes and failures here)

 

 

2. Global configuration of Hudson

Next, set Hudson globally. Click Manage Hudson in the list on the left, and then click Configure system. You can configure the Hudson system, including global path and variable settings. For example

 

 

(1): system message. Of course, this is something on the surface. You can write something casual, such as hellohudson, and get a logo image or something. It also supports the HTML language, you can make this welcome interface quite beautiful.

(2): The quiet period value indicates that you can wait for your build to prevent the build from starting during code submission. This is a global variable. I am used to setting it in each project, because the projects I set up using Hudson have SVN and VSS, and the wait time value will definitely be different. (If you want to set it here, you can view the "help" on the right ")

(3): Enable Security: Set the Hudson permission. After this option is selected, for example:

The default settings can be retained here. If you want to perform corresponding permission operations on each user, select the project-based matrix authorization strategy option under the authorization item to perform corresponding settings, as shown in:

The default settings can be retained here. If you want to perform corresponding permission operations on each user, select the project-based matrix authorization strategy option under the authorization item to perform corresponding settings, as shown in:

 

 

 

(4) set global properties by default.

(5) The setting in Maven is to get a name and specify the decompression path of maven2 in the path. As shown in

 

 

 

 

 

 

 

 

When setting here, I usually remove install automatically, but directly specify maven_home, my Maven is installed in C: \ Program Files \ apache-maven-2.2.1-bin \ apache-maven-2.2.1 (depending on my personal settings) Here, enter it directly.

(6) JDK settings

JDK settings are required. If you do not set the JDK path here, this error may be reported during the build project, as shown in,

 

 

Therefore, the correct setting is to remove the install automatically option and enter the name and java_home directly.

My java_home is installed in c: \ Java \ jdk1.6.0 _ 02, So enter it directly. The JDK settings are as follows:

 

(7) Shell, ant, Maven, CVS, and so on. I will not introduce it here. If you want to learn more, the "help" (the blue question mark on the right) on the Right will be of great help.

(8): e-mail Notification is mainly an email reminder. You do not need to set it. If you are interested, you can set it like this. For details, refer to the blue question mark on the right.

SMTP server --> mail server address (127.0.0.1)

Default User e-mail suffix --> email suffix (@ 123.com)

System admin e-mail address --> Administrator Account 123@123.com

Hudson URL --> access Hudson URL (http: // 127.0.0.1: 8080)

Now, the global configuration of Hudson is almost ......

3. Start creating a job

Click new job in the list menu on the left. The following page is displayed:

 

Enter the job name, select build a maven2 project, and set it according to your project. Here we will talk about the maven2 project, and click OK. Go to the job settings page (here is the focus, here we can see the greatness of Hudson, how to integrate maven2 project and SVN), as shown in

 

 

(1): The project name has already been named when you set up the project, testjob. If you want to change the name one day, you can change it here.

(2) Description: Describes the testjob project, including the project participants, project start and end dates, and so on, it can be said that this is the beautification interface + project description + prompt information, etc. I don't have many requirements for interface beautification, so I will leave it for you to study.

(3): We recommend that you enable this option for discard old builds. (Hudson has an option to check out the project from SVN, however, the project can only be located under % hudson_home %/jobs/projectname/workspace. I think this is an unreasonable way, it is normal that everyone will create a project under their own directory, and then use Hudson to build the environment.

 

Advanced project options: This indicates that you can set up your project build. It includes two small options,

(1). Quiet Period: the time can be set according to the project's needs. Oh, I almost forgot. The time here is the time difference between the build start and the project start. For example, I set this time to 300 s, it indicates that testjob will have 5 minutes of buffer before it starts building. This is very user-friendly, because if a large amount of code needs to be submitted, it will take a long time, if there is no waiting time, it is easy to see less code, leading to the failure of the entire build process.

(2 ). use custom Workspace: You can put the items that can be published in a specific directory, and set the values here to this directory, such as: D: \ Hudson \ jobs \ testjob \ builds.

 

Source code management

Enter your repository address in the repository URL. SVN has two types of addresses: http ://..... in this case, SVN ://...... I am using the second method, so fill in SVN: // 192.168.0.245: 56581/mydemo

(Note: This is the root directory of the project, that is, the directory where Pom. XML is located. Do not enter the directory SVN: // 192.168.0.245: 56581/demo/src. Pay attention to it !!!)

Use update: After the options are checked, the svn update command will be used each time the database is detected to have an update. if not checked, the svn checkout command will be used each time, the reason is that update is much less time than the checkout command.

 

Build triggers: you can understand how you want to trigger your build, based on other successful builds, periodic builds, or changes based on Poll SCM) to trigger the build.

I used to build periodically and input 0 *** in schedule ***.

Note: The configuration rule of schedule is composed of five characters separated by spaces, represented from left to right: minute, day, month, and year. * Represents all. For more information, see the small blue question mark on the right.

0 12, 20 * Indicates building at and on any day of any year or month

 

 

There are no special settings for build and build settings.

Post-build actions.

 

☆Automatic deployment of Hudson:

After a project is successfully built, Hudson will release a war package for the project under % hudson_home %/jobs/projecct_name/workspace/projecct_name/target. (Note: project_name is your project name. hudson_home is generally under c: \ Documents ents and Settings \ USERNAME \. Hudson. Here, username is your current system user with a guest account or administrator. Haha, isn't the comment boring? For popularization, sorry .) However, if we want to see how our project progresses after the build is successful, we want to load the war package through tomcat to see the effect, we have to manually copy the war package to Tomcat's webapp and start Tomcat. This is a simple automatic deployment method. You can use a Hudson plug-in. Now, the plug-in mentioned above plays a major role. Click Manage in the list menu on the left
Hudson, and then select the third manage plugins. The function of this option is to manage the Hudson plug-in, or directly enter: http: // localhost: 8080/Hudson/pluginmanager /) this shows how powerful the scalability of Hudson is. Click advanced in the plug-in management center and upload the downloaded plug-in the upload plugin, after the upload is complete, you need to restart Hudson to complete the installation (that is, restart Tomcat). After restarting, click New job, and then create a new job (the existing project, directly click to enter the project, click Configure in the function menu on the left.
Deploy war/ear to a container. Here war/ear file: Enter the path of the war package prepared by Hudson. As mentioned earlier, the war package prepared by Hudson is put here, so the name of % hudson_home %/jobs/projecct_name/workspace/projecct_name/target/your war file is written here. war. Select your tomcat version for container. Manager User name: Enter the Tomcat user name. The default value is admin,
Manager password: Enter the Tomcat password, which is empty by default. Tomcat URL: Fill in http: // localhost: 8080/and it will be OK. Now you can save it. In this way, when you build this project again, the war file is automatically deployed to your Tomcat webapp directory. Shows how to set