In part 1, 2 and 3 I showed you how to create a simple MSBuild script and how to execute it from the command line. We had a look at how to clean your output directories, download the Nuget packages, compile your code, run MSpec tests and creating a code coverage report. In this last part of this series I will show you how to integrate it with Jenkins. First of all we want Jenkins to pull the latest code from Github as soon as somebody has pushed new code to Github. To do this we need to install the Github plugin in Jenkins. We will also install the “MSBuild plugin” in Jenkins to be able to use MSBuild in Jenkins and the “Html publisher plugin” to publish the Coverage and MSpec reports. Also install the “Jenkins Git plugin” to configure the repository in Jenkins.
In the previous parts (part 1, part 2) of this series I described how to clean, download Nuget packages and build your solution using MSBuild. In this part I will explain you how to create a MSpec MSBuild target and a Code coverage MSBuild target. MSpec is a testing framework which enables you to write living specifications. Using the MSpec console runner you can easily generate an html report. This report can later on be published using the Jenkins report plugin. By publishing this report we have some documentation on the specifications of the software available and because we did write the specifications using MSpec we also have unit tests in place. So that’s why I call it living documentation. :D For generating the code coverage report we use the xml output of our MSpec tests. These reports will also be published using the Jenkins report plugin. To do so I use OpenCover and ReportGenerator. All three packages are installed in my solution using Nuget. So the paths in my build script are based on the paths of my source/packages folders.
In part 1 of this blog series we had a look at a very basic MSBuild script which enables us to compile our projects. For doing this I provided you guys with a simple batch file to make it even more simple to execute the build script. In this episode we will focus on cleaning the folders before building again and getting the Nuget packages using Nuget package restore. The latter I will explain further for you first. Nuget package restore can be enabled in Visual studio. A best practice is to enable this always, because then we won’t have to put all Nuget packages in source control. By enabling it, every team member will download the missing packages automatically when building his project in Visual Studio. However the build server won’t do this by default so we create a custom target in our build script to make this happen.
Very lately I have worked on setting up some continuous integration (CI) using MSbuild for my c# project. In this blog series I will explain to you how to set up continuous integration. First of all we will start with creating a MSBuild script which will compile our code. We will also create a small batch file for easy executing the MSbuild script. When that is in place, we will add several targets to the build script to run for example unit tests, integration tests, code coverage, packaging etc. So we will take the agile approach and improve our build process based on validated learning. First of all we need some basic knowledge about MSbuild. I think there are enough pages around on the web which will give you a basic introduction. A good starting point would be the MSDN documentation for MSBuild. Let’s consider we have the following project structure within our Git repository / local file system. 12345src (contains our source code)|- lib (contains build output, and third party libs not available on nuget)|- reports (contains code coverage reports, test scenarios and test results)|- ci.msbuild (your msbuildfile)`- ci.msbuild.cmd (your batch file to execute the build on your local machine)