This post show a simple and effective way to setup a continuous integration server and a way to update a test environment on each commit on a developer branch.
Our domain is a compositions of these elements:
- .NET Solution (the project)
- Git repository (Stash)
Target
We want to create e new continuous integration environment using Jenkins to build .NET solutions.
Agenda
- Jenkins introduction and installation
- Configure Jenkins
- Install Plugins
- Manage Jenkins settings
- Create a new Job
- Set Source Control
- Build Triggers
- Build: create a custom script in order to create a package that can be deployed
- Automatically FTP Deploy via Jenkins
- Automatically run a new “build and deploy” after a commit on the develop branch.
Jenkins introduction and installation
What is Jenkins?
Jenkins is an application that monitors executions of repeated jobs, such as building a software project or jobs run by cron. Among those things, current Jenkins focuses on the following two jobs:
- Building/testing software projects continuously. In a nutshell, Jenkins provides an easy-to-use so-called continuous integration system, making it easier for developers to integrate changes to the project, and making it easier for users to obtain a fresh build. The automated, continuous build increases the productivity.
- Monitoring executions of externally-run jobs, such as cron jobs and procmail jobs, even those that are run on a remote machine. For example, with cron, all you receive is regular e-mails that capture the output, and it is up to you to look at them diligently and notice when it broke. Jenkins keeps those outputs and makes it easy for you to notice when something is wrong.
For more details (http://jenkins-ci.org/)
Pre-requisite
Before installing Jenkins you must download and install Git.
For the most part, you’ll select command-line setting, with the exception of Git command line stuff. In that case, select “use git from the Windows Command Prompt,” as shown below.
Now you can install Jenkins.
The install wizard will open the Jenkins web page.
Configure Jenkins
Install Plugins
Without these required Plugins you will not be able to build and test .NET solutions. In order to add essentials plugins you must go to “Manage Jenkins” > “Manage Plugin”
Required Plugins:
- The Build Plugin we’ll be using is MSBuild this allows us to build a .NET solution.
- The GIT Plugin – This plugin allows use of Git as a build SCM.
- Testing plugin (You’ll need one of these depending on your chosen test framework)
- MSTest Plugin – This plugin converts MSTest TRX test reports into JUnit XML reports so it can be integrated with Jenkins JUnit features.
- NUnit Plugin – This plugin allows you to publish NUnit test results.
- xUnit Plugin – This plugin makes it possible to publish the test results of an execution of a testing tool in Jenkins.
- Gallio Plugin – This plugin makes it possible to publish Gallio/MbUnit test results.
Tick the check box next to each of the required Plugins and then click the ‘Download now and install after restart’ button.
Optoinal Plugins
- Green Balls – Changes Hudson to use green balls instead of blue for successful builds. Who doesn’t want Green Balls!
- Active Directory Plugin – With this plugin, you can configure Jenkins authenticates the username and the password through Active Directory.
Manage Jenkins settings
Go to “Manage Jenkins” > “Configure System”
Enter and go to the Git section and set the fields with your current Git installation described above.
After that you must config the “MSBuild installations …” (click to open)
Please select your own path for MSBuild.exe
Click Save.
Create a new Job
In Jenkins the definition of a build process is called a Job. Jobs are created using the main menu on the Jenkins home page. We’ll create a basic Job that will checkout our source and build the solution.
From the main Jenkins menu, Click the ‘New Item’ link.
You now see the New Job configuration page.
Set your own name (Test in this case) and select “Freestyle Project” and select “Ok”
Jenkins will now create the Job workspace on disk and redirect you to the job configuration page.
Next we’re going to checkout our solution from source control and build it. So we first need to give Jenkins details of our source control server.
Set Source Control
For the purpose of this demo we’ll use Git.
Lets setup our Job to grab the source code from this repository. This is done in the” Source Code Management” section of the configuration page.
- Select the Git radio button.
- Provide the git project url ang give the right username/password entry in order to connect Jenkins to the repository.
If can create a new user by clicking the aside “Add” button to do this.
After taht you can change the “Branches to build”. We choose to check-out the develop branch.
Git is now configured and we can move onto Build Triggers.
Build Triggers
We want to trigger a build every time our source code changes; we achieve this by creating a “Build Trigger” which polls our source code repository. When a change is detected a new build is triggered and a new deployable package is generated.
Under the Build Triggers section, tick the Poll SCM checkbox.
By clicking on (?) you will read more about the configuration instruction for the “Schedule” field. These are the instruction:
==================================================================================
This field follows the syntax of cron (with minor differences). Specifically, each line consists of 5 fields separated by TAB or whitespace:
MINUTE HOUR DOM MONTH DOW
| MINUTE | Minutes within the hour (0–59) |
| HOUR | The hour of the day (0–23) |
| DOM | The day of the month (1–31) |
| MONTH | The month (1–12) |
| DOW | The day of the week (0–7) where 0 and 7 are Sunday. |
To specify multiple values for one field, the following operators are available. In the order of precedence,
*specifies all valid valuesM-Nspecifies a range of valuesM-N/Xor*/Xsteps by intervals of X through the specified range or whole valid rangeA,B,...,Zenumerates multiple values
To allow periodically scheduled tasks to produce even load on the system, the symbol H (for “hash”) should be used wherever possible. For example, using 0 0 * * * for a dozen daily jobs will cause a large spike at midnight. In contrast, using H H * * * would still execute each job once a day, but not all at the same time, better using limited resources.
The H symbol can be used with a range. For example, H H(0-7) * * * means some time between 12:00 AM (midnight) to 7:59 AM. You can also use step intervals with H, with or without ranges.
The H symbol can be thought of as a random value over a range, but it actually is a hash of the job name, not a random function, so that the value remains stable for any given project.
Beware that for the day of month field, short cycles such as */3 or H/3 will not work consistently near the end of most months, due to variable month lengths. For example, */3 will run on the 1st, 4th, …31st days of a long month, then again the next day of the next month. Hashes are always chosen in the 1-28 range, so H/3 will produce a gap between runs of between 3 and 6 days at the end of a month. (Longer cycles will also have inconsistent lengths but the effect may be relatively less noticeable.)
Empty lines and lines that start with # will be ignored as comments.
In addition, @yearly, @annually, @monthly, @weekly, @daily, @midnight, and @hourly are supported as convenient aliases. These use the hash system for automatic balancing. For example, @hourly is the same as H * * * * and could mean at any time during the hour. @midnight actually means some time between 12:00 AM and 2:59 AM.
Examples:
# every fifteen minutes (perhaps at :07, :22, :37, :52) H/15 * * * * # every ten minutes in the first half of every hour (three times, perhaps at :04, :14, :24) H(0-29)/10 * * * * # once every two hours every weekday (perhaps at 10:38 AM, 12:38 PM, 2:38 PM, 4:38 PM) H 9-16/2 * * 1-5 # once a day on the 1st and 15th of every month except December H H 1,15 1-11 *
==================================================================================
Finally we just need to tell Jenkins how to build the solution when changes are detected. This is done via the “Add build step” button under the Build section.
Build: create a custom script in order to create a package that can be deployed
We want to reach this goal: provide a visual studio solution ==> generate a build ==> run tests* ==> create a publish package ==> deploy via ftp.
* not included yet in these guide.
In order to accomplish these steps we start from “Add build step” and in this instance select “Execute Windows batch command”.
The publish.bat script in our case make these steps:
- set path variables for project, destination foldert, etc.
- build the .NET solution with a specific configuration (Test, Release, etc.)
- copy the created package into a destination folder in order to be moved via FTP on a specific Test server.
set msBuildDir=C:\Program Files (x86)\MSBuild\12.0\Bin set slnPath=C:\myProjectSolutionPath set packagePath=C:\myProjectSolutionPath\Project.Web set deployPath=C:\DEPLOYED_APPS\ProjectName rd %deployPath%\CI_Release /S /Q md %deployPath%\CI_Release call %msBuildDir%\MSBuild.exe %slnPath%\myProject.sln /p:Configuration=Release /l:FileLogger,Microsoft.Build.Engine;logfile=Manual_MSBuild_ReleaseVersion_LOG.log XCOPY %packagePath%\obj\Release\Package\PackageTmp\* /S %deployPath%\CI_Release\
Automatically FTP Deploy via Jenkins
… Coming soon …
