Build a continuous integration environment with MSBuild and Jenkins (2)

Http://www.infoq.com/cn/articles/MSBuild-2

Author Mustafa Saeed Haji Ali, translator Jian Li released on October 23, 2012 | Note: Swing the sleeves, take away full of dry goods, focus on the activities of the camp, from time to time hair benefits yo! 3 Discussions

• Share to: Weibo facebooktwitter Youdao Cloud Note email sharing
• Read later
• My list of reading

This is the bottom half of the Continuous integration series, if you haven't seen the top half, click here: Build a continuous integration environment with MSBuild and Jenkins (1).

Meet Jenkins

Jenkins was created by Kohsuke Kawaguchi in 2004, and the first name was Hudson. Kawaguchi was working at Sun, and Sun continued to support Hudson until 2008, but when it was acquired by Oracle, there was disagreement between Oracle and Hudson's developer community. In 2011, Oracle claimed ownership of the Hudson Trademark, and the Hudson Development Community changed the name of Hudson to Jenkins, getting rid of Oracle's interference and continuing its development efforts.

At first glance, Jenkins is like a continuous integration tool for Java projects: There are jobs designed for MAVEN projects, there are many default plugins for Java projects, not to mention plugins written in Java.

But Jenkins is actually a very flexible tool that can be combined with various versioning systems and build tools to build any type of project. In this article, we'll take advantage of its flexibility to pull code from mercurial and build the project with MSBuild. First, we need to download and install Jenkins, and then install the mercurial and MSBuild plugins.

Configuring Jenkins

Download the installer from the official website. Its Windows installation package is simple and will install Jenkins as a Windows service. The default access path for Jenkins is http://localhost:8080, make sure that port 8080 is not occupied by other applications.

After installation, the plug-in is installed. Please click on the "Manage Jenkins" link and then click "Manage Plugins". On the "Available" tab, you can view the currently installable plugins--you need to have an Internet connection in order to see the contents of this page. Use the filter to locate the mercurial and MSBuild plugins, and click the Radio box in front of the plugin name to install it. You can click on the "Installed" tab to make sure that the two plugins have been installed successfully. During the installation, you may see a message saying that Jenkins needs to restart to complete the installation, please let it restart, and then visit the "Installed" tab to see if the installation was successful after the reboot.

The mercurial plugin also needs to be configured to let Jenkins find the mercurial installation path. Go back to the "Manage Jenkins" page and click on "Configure System" to find the "Mercurial" part--If you can't find "Mercurial", it means the Mercurial plugin is not installed--click "Add Mercurial "button, you need to give the Mercurial instance a name (the more convenient you use the better), you also need to enter the installation path of the Mercurial executable, where the Hg.exe file is located, and finally the name of the executable file, use" Installation/hg.exe "Just fine, installation this word will be replaced by the previously entered installation path.

Create a Jenkins Job

Click "Back to Dashboard", return to Dashboard, then click on the "New Job" link. You'll see a set of job types, choose "Build a Free-style software project", name it "Helloci-rununittests" and click OK.

The next step is the job Configuration page. There are many configuration items on this page, and most of them come with detailed descriptions, which can be seen by clicking the Help icon on the right. We now only configure two parts, one is where the code base is located, and the other is how to build the project with MSBuild.

Locate "Source Code Management" and select Mercurial. In the Mercurial Version input box, enter the name of the Mercurial that you previously configured in Configure System. Then enter the URL of the mercurial repository (or the path to a file system) in the repository URL. Finally, enter the name of the branch you want to track in branch.

Next to the "Build" section. When you click the "ADD Build Step" button, a series of step types will appear in the drop-down box, including "Build a Visual Studio project or solution using MSBuild", if you don't see this option, This means that the MSBuild plugin is not installed correctly.

After clicking "Build a Visual Studio project or solution using MSBuild", enter the name of the build script in the "MSBuild Build File" input box: Helloci.msbuild. We want Jenkins to execute the "rununittests" target, and if you don't set the DefaultTargets property to Rununittests, you can enter "/t:" in Command line Arguments. Rununittests ", where/T is a shorthand for/target.

Once the job is triggered by clicking "Save" or "Apply", you can pull the code down, compile the project, and execute the unit test. Let's start by manually triggering it once to see if the configuration is correct. Go back to Dashboard, and you'll see our job in the middle of the screen. Click on the job name and find the "Build now" link in the link on the left, click on it and Jenkins will start executing. Below this set of links there is a "build history" list that shows all the build histories of the job, and when the first build starts running, you'll see a progress bar in the list, along with a small sphere showing the build status. A blinking ball indicates that the build is in progress and that it stops blinking when it is generally red or blue, red indicates a build failure, and blue indicates success.

If the job has access to the mercurial repository, and the Helloci.msbuild script is found, the "rununittest" execution succeeds and the orb should turn blue. That's when you finished the first Jenkins build. If the build fails, click on the number of "build history" to see the details and then click "Console Output" to see every command and result that Jenkins executes, from which you can analyze the cause of the build failure.

Trigger Build

After the build is successful, the next step is to let Jenkins detect the changes to the repository, and once the code is submitted, Jenkins will pull the code and execute the build. There are several ways to do this. The simplest thing to do is to have Jenkins build it on time, but if there is no code to commit for a while, this build is wasted. Another way is for Jenkins to poll periodically to see if the repository has code submissions. The disadvantage of this approach is that when the code is submitted, Jenkins waits until the next polling cycle to perform the build. Of course, you can also ask Jenkins to poll every minute for as little latency as possible, but there's another more elegant solution--Put a post-commit hook in the mercurial repository so that once the repository accepts new code, it notifies Jenkins, Let it start building at once.

This method needs to add a hook in the configuration file (. hgrc) in the. Hg directory. In this hook, you need to let mercurial visit the following URL: http://localhost:8080/job/JOBNAME/build?delay=0sec (JOBNAME need to replace the real job name), Let Jenkins start the build. Unfortunately, there are no tools like Linux wget that allow HTTP requests to be made under Windows. I wrote the Ruby code myself to do the work. You can also use PowerShell to create an instance of System.Net.WebClient, and then call the Downloadstring method. A reader friend can do the work by himself, and exercise it right.

If you are not willing to use this method, you should also use polling. Go back to the Job Configuration page, select Poll SCM in the "Build Trigger" area, and enter the polling cycle in the "Schedule" input box. It uses a syntax format that is cron style. If you want to poll every minute, enter "1 * * * *". You can click the Help button on the right side of the input box to see a syntax introduction to the polling cycle.

Build pipeline

Jenkins can start another job after a build has completed successfully. So there is the build pipeline, which is the concept of a job after a successful trigger other job. The trigger is called the upstream job, and the trigger is called the downstream job.

There are a number of scenarios for building pipelining: allowing long-running tests to be performed after the unit tests are completed, run static code checks, and deploy the build results to a test environment (staging) or product environment. Let's demonstrate this feature so that Jenkins starts the Web server at the end of the build and runs the Helloci app.

There are only three things we need to do: the helloci-rununittests job triggers a new job, copies the helloci-rununittests's build results, and starts the Web server. Before you begin, you will also need to install the copy artifacts plugin. Back to the Manage Plugins page, refer to installing copy artifacts before installing the mercurial plugin method. Restart Jenkins when you see the prompt to restart.

Before creating a new job, we need to tell the helloci-rununittests job to save the build product for use by the new job. Go back to the helloci-rununittests job configuration interface, find "Post-build Action", select "Archive the Artifacts", a text box appears on the page: "Files to Archive". We have two directories to archive, one is the Buildartifacts directory, one is the packages directory, and the latter is to allow us to access the NuGet package. If you want to specify a directory and all the contents of the directory, you need to follow the directory with a slash and two asterisks. Separate directories or files with commas. Here we enter "buildartifacts/**,packages/**".

Now create a new job named "Helloci-startwebserver". On the configuration page, in the "Build Triggers" section, select "Build after another projects is built" to configure the previous job as the project to trigger the current job.

Next, add a build step to the job, and the first thing that the job does is copy the build that the job saved. This step is used for copy artifacts from another project (which is provided by the copy artifacts plugin). We just need to fill in the name of the helloci-rununittests job.

Finally, add a build step to start the Web server. With Execute Windows Batch command, we run the app with the Cassini provided by Visual Studio. Cassini can be found in "C:\Program Files (x86) \common Files\Microsoft Shared\devserver\10.0\webdev.webserver40.exe". Running Cassini is simple, pass the path that the Web application holds as an argument, and if you don't specify a port number, it will use the default port number 80.

The Execute Windows Batch command step requires a command that can be executed in the directory after the buildartifacts and packages copies. Let's copy the following command into the "command" input box:

"C:\Program Files (x86) \common Files\Microsoft Shared\devserver\10.0\webdev.webserver40.exe"/port:9876/path buildartifacts/_publishedwebsites/helloci.web/.

This command starts the Cassini, points it to the copied application, and then starts the server on port 9876.

All configurations are ready. Try modifying the code and submitting it. Jenkins should be able to monitor changes and run helloci-rununittests. If the code compiles successfully, all tests are passed, and Jenkins should start running the Helloci-startwebserver job, copying the helloci-rununittests build product and starting Cassini on port 9876. If all this works, our continuous integration system will be ready.

End

There are a lot of places that MSBuild and Jenkins can talk about. For example, you can move from continuous integration to continuous deployment. All you need is a job to deploy the build product to the production environment (translator Note: Continuous deployment is not easy, the author is a bit exaggerated, readers should not be gullible). Asp. NET, it is easier to use a job to copy the build product to a directory. That way, as long as all the tests pass, the Jenkins job can post the latest features to the production environment.

If you're not ready to go that far, you can use promoted build plugin, which can be labeled "recommended" after a build has reached a specific standard. A person or several people manually audited a build, also is to achieve the recommended standard. With promoted Build plugin, the changes people make can be automatically published to the development server, and all new features are presented centrally. The development manager can then recommend a particular build to the test environment. The QA team or other stakeholders can perform the acceptance (by recommending a build on a test environment), and the build can then be deployed by Jenkins to the product environment.

John Ferguson Smart has written a very good book called "Jenkins:the Definitive Guide". In addition to the functions of Jenkins, this book describes how to ensure the security of Jenkins, how to detect resource usage (such as disk occupancy), how to build it distributed, until a notification system is set up to allow users to be notified when the build starts, succeeds, and fails. The book was published by O ' Reilly and purchased at this address. If you don't know much about Jenkins, this book is a must-see.

Having an automated build deployment system is just as important as testing and using a version control system. I hope you have mastered how to set up a continuous integration system, and you can start to integrate your own system.

Don't be too aggressive at first, just think about doing everything well. You can come at 1.1 o '. You'll finally enjoy the victory. When Jenkins notifies you that a build has failed, you find that the timing of the bug is ahead of time, and you have a systematic deployment process when you no longer have to memorize every step of the deployment. And more importantly, you have more time to do more important things, such as developing valuable features or preparing for new projects, or getting home early from work, without worrying about upcoming online.

About the author

Mustafa Saeed Haji Ali lives in the Hargeisa of Somaliland. He is a programmer, and the most common is ASP. NET MVC. Mustafa like to test, like to use JavaScript frameworks, such as Knockoutjs, AngularJS, SignalR. He is passionate about disseminating best practices.

View English Original: Continuous integration with MSBuild and Jenkins–part 2

Build a continuous integration environment with MSBuild and Jenkins (2)