. NET continuous integration practice-Jenkins

Now in this project, we use jenkins (formerly hudson, http://www.jenkins-ci.org/) as the CI server, open source is certainly the most basic consideration, and this decision is influenced by the former boss, jenkins is a good choice in the java ecosystem. Now we use this project. net technology, can it be used very well? A little worried, all the way to see the Buddha, see the magic and kill the magic, bumps and bumps, and now it is basically set up. The basic combination is jenkins + svn + msbuild + mstest + javasxec. Many problems have also been encountered during the construction process. Some problems have been solved and some problems have been bypassed, some problems cannot be solved until now. Now, let's take a brief look at this process and I hope it will be helpful to you.

 

Jenkins Server Selection

At the beginning, our jenkins server was running on linux. It was built simply by installing java development. As we all know ,. net requires the use of nant/msbuild for building, the most fatal is dependent on.. net framework, we can only move jenkins to windows 2003/2008, and out of careful consideration, we finally decided to choose msbuild. Jenkins supports msbuild and can be used with related plug-ins. The support for version control is naturally no problem. jenkins supports several mainstream Version Control Software by default. In unit test, mstest is preferred, because this is also true. net 4.0/vs 2010 embedded in a component, and in vs 2010 can create a variety of test projects of different needs, so we do not select nunit, of course, jenkins also supports mstest, of course, some problems have been encountered in the support of the test report. Of course, if jenkins supports svn, msbuild, and mstest, the need for continuous integration for A. net project will be basically met.

 

Jenkins installation and some initial work

Download the latest jenkins version from Jenkins's official website (http://www.jenkins-ci.org/) and install it on our windows 2008 R2. Jenkins is automatically installed as a windows service: Jenkins. By default, port 8080 is used to open http: // localhost: 8080/to open the main interface of jenkins. Go to Manage Jenkins-> Manage system, select Jenkins's own user database-> Allow users to sign up, click sign up in the upper right corner, and register a pm account first, then, determine whether to Allow the team members to create their own accounts as needed. If not, deselect Allow users to sign up. Next, log in to Manage Jenkins-> Manage Plugins and select the components we need:

Subversion plugin, Jenkins MSBuild plugin, Jenkins MSTest plugin, and Version Number plug-In.

In this way, Jenkins preparation is almost the same. Besides, there are still some problems with Jenkins plug-in updates. For example, the new version of Subversion plugin is a bit problematic, in addition, the version rollback is slightly problematic.

 

Continuous Integration Practice

For continuous integration, we only adopt a relatively basic continuous integration practice. Code changes are regularly polling from svn every day. If there is any code change, it will be compiled through msbuild and then proceed to the next step, compile the unit test solution, and then run the unit test through mstest. If a test case fails, an email is sent to the team; otherwise, the next step is to build the deployment package, generate an installable software version, including the server, database, and smart client. Then, the Local Area Network Disk ing is established through net use. All released software versions are copied to the test server on the local area network, and the latest software version is remotely deployed on the test server through ipvxec. After the deployment is complete, compile the integration test solution, and then use msbuild to test the integration of the Service released on the test server (our integration test mainly tests the service, and the smart client is handed over to the test team for system testing to overwrite) and the test report is sent to the team. If this series of links are executed normally, it indicates that continuous integration is normal. Otherwise, an error occurs in any link and an email is sent to the team.

In addition, the frequency of integration is about once an hour, so unit testing is also once an hour, but the frequency of release and integration testing is tentatively set to once a day.

 

Jenkins Project Planning

Based on our continuous integration philosophy, we need to create two Jenkins projects, one for code building and unit testing, and the other for release, deployment, and integration testing. So what solution will be compiled in each Jenkins project is clear at a glance. The names of these two projects are tentatively set to ABC Build and ABC Publish.

 

Jenkins project configuration

First, select the style of the project. Here we select Build a free-style software project.

Source control management, select Subversion, set the svn address of our project, and then prompt you to provide svn verification. Next, start building Triggers and Build periodically: @ hourly.

Version Number: in the development phase, the Version Number format is 0. {# of phase}. {# of month in current phase}. {# of successfully build of current month }. This can be determined based on your actual needs. Because we chose smartclient/clickonce for deployment, therefore, we need to determine the version number management in advance (you need to specify the version number when Publish/Deploy client program ).

Next, Add build step: Build a visual studio project or solution using MSBuild. MSBuild version: {Default}, MSBuild file: solution file, Command line arguments:/t: build/p: Configuration = Release. Among them, MSBuild build file should note that what is the solution file path? It is based on the relative path of the workspace. This must be set correctly.

How does one execute a unit test through msbuild? The build step to be added is Execute Windows batch command, which uses the mstest command:

Mstest/testcontainer: ***. Test. dll

I didn't specify the/resultfile here because I encountered some problems when configuring the resultfile. The format of the test result file produced after mstest executes the test is. trx, while configuring a general test result file in Jenkins, we found that mstest could not be executed normally, so the test report of our project is still problematic, if you have good practical experience, please share it with us. In addition, because Jenkins supports JUnit testing reports by default, Jenkins MSTest reports mainly convert. trx to JUnit testing reports, which can be displayed in Jenkins. I did not try this one.

 

Next, build deployment packages is also completed using msbuild, but it is completed by calling windows batch command:

Call Deployment/ABC. Server/BuildABCService. bat

Call Deployment/ABC. Database/BuildABCDatabase. bat

Call Deployment/ABC. Client/BuildABCClient. bat % ABC_VERSION %

 

After the deployment package is compiled, You need to copy it to the test server in the LAN. This is done by calling the windows batch command, which is roughly as follows:

@ Echo off
Set ver = % 1
Set lcf = Shell _ % VER:. = _ %

Net use \ 1.2.3.4 \ DropLocation/user: test server name \ account password
Rem xcopy/s DropLocation \ 1.2.3.4 \ DropLocation/y

Xcopy/s "DropLocation \ ABC Deployment \ ABC. Database" "\ 1.2.3.4 \ DropLocation \ ABC Deployment \ ABC. Database"/y

...

Net use \ 1.2.3.4 \ DropLocation/delete

 

The next step is remote deployment, which is implemented through ipvxec. There are still problems with remote deployment. For details about the specific process, refer to the article titled prepare xec issues with Jenkins:

@ Echo off
Echo Start to update ABC Database...
Export xec \ 1.2.3.4-u account-p password-n 60-s-h "C: \ DropLocation \ ABC Deployment \ ABC. Database \ DeployABCDatabase. bat"-accepteula

Currently, manual remote execution is acceptable, but the automatic deployment has not been completed yet because of problems encountered when the slave xec is executed through Jenkins. Haha. Therefore, there is no way at present. The integration test depends on temporary manual deployment. Therefore, another Jenkins project has been created for the current integration test for scheduled execution.

 

These are the CI practices of our current project. This is a brief introduction, which is difficult to serve as a reference for actual operations. However, it can be used as a reference for ideas. If you encounter problems during the configuration process, you are welcome to discuss it together.