Switch on vim colour

Do your self a favour and switch on git colour it makes the command line output much easier to read.

git config --global --add color.ui true

Remote branches

Working as part of a team at some point you’ll need to take a look at a team mates branch, first they need to push their branch up to github.

git push origin -u my-awesome-new-feature

Pull down a team mates branch

Don’t know or can’t remember the remote branch name?

git branch -r

Next you need to create a local branch that tracks the remote branch.

git checkout --track origin/my-awesome-new-feature

This command creates a local branch named my-awesome-new-feature which is tracking the remote branch. Now when you push your changes the remote branch will be updated.

• More info on stackoverflow

Fix a conflict

When you have a conflict in a feature branch you’ll not be able to auto merge on github you’ll need to merge the branch manually.

1
2

git checkout master
git merge my-awesome-new-feature

Fix any conflicts.

• Check out this vimcast for a nice way to fix conflicts in vim using the fugitive plugin.

fugitive.vim: a Git wrapper so awesome, it should be illegal

Finally git push the merge up to github and you’re done.

List of basic commands to use during feature branch workflow.

Create feature branch

1

git checkout -b my-awesome-new-feature

NOTE: The -b parameter means branch, it saves us having to use two separate git commands. Without this option we’d need to branch then checkout.

Now do lots of work on the new feature…

Find out what has changed

When finished working on the new feature find out what has changed.

1

git status

Add changes to git

Either add each file manually using:

1

git add my-changed-file.txt

Or add all the files in the current directory.

1

git add .

Run git status one more time to get a list of everything that is going to be committed.

NOTE: Accidentally added files can be removed using the command git rm <filename>

Commit changes

Commit your changes with a meaningful message.

1

git commit -m "my awesome new feature, this changes everything!"

Push changes

Push the new feature up to github so we can do a pull request.

1

git push origin -u my-awesome-new-feature

The new branch should now be visible on github and we can now issue a pull request.

This post is part of a series:

1. Jenkins.NET
2. Jenkins.NET Plugins
3. Setup Jenkins.NET
4. Setting up your first job
5. Your first build
6. Breaking the build
7. Diagnosing and fixing a broken build
8. Monitoring your build
9. Running your tests
10. Code Analysis
11. Security
12. Active Directory Security

• BONUS: Jenkins for .net in 5 Minutes

For my final post on using Jenkins with .net, here’s how to set it all up in 5 minutes!

Install

1. Download the latest version of Jenkins from: http://mirrors.jenkins-ci.org/windows/latest
2. Extract the setup files from the zip file.
3. Run the Setup.exe.
4. Accept all the defaults in the setup wizard.
5. Jenkins will now be installed and the main Jenkins page will be open.

Add required .NET Plugins

1. Download and install your required .NET framework from: http://www.microsoft.com/net/download
2. Open the Manage Plugins page, from the Jenkins menu select Jenkins » Manage Jenkins » Manage Plugins.
3. Click the “Available” tab.
4. Tick the “MSBuild” plugin.

Add optional .NET Plugins

1. Tick the plugin for the source control management software your using.
2. If you want to run unit tests as part of your build Tick your chosen testing plugin, this guide will use NUnit.
3. Tick the “Active Directory Plugin” if you want to use Active Directory for Authentication.

Setup Jenkins

1. Open the main setup page, from the Jenkins menu select Jenkins » Manage Jenkins » Configure System.
2. Under the MSBuild section, click the “Add MSBuild” button.
3. Set the name and path to MSBuild for example: Name: v3.5 Path to MSBuild: C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe
4. Click the “Save” button.

Setting up your first job

1. From the Jenkins menu click Jenkins » New Job.
2. Set Job name for example: Demo.
3. Select the “Build a free-style software project” radio button.
4. Then click the “OK” button.
5. Jenkins will now create the Job workspace on disk and redirect you to the job configuration page.

Source Control

This guide will use Subversion but there are many available.

1. Under the Source Control Management section select the “Subversion” radio button.
2. Set the Repository URL for example: https://jenkins-net-demo.googlecode.com/svn/trunk

Build Triggers

1. Under the Build Triggers section, tick the Poll SCM checkbox.
2. Enter “5 * * * *” in the Schedule text area, this translates to check for changes every 5 minutes.

Build the Solution

1. Under the Build section click the “Add build step” button and select “Build a Visual Studio project or solution using MSBuild”.
2. Set “MsBuild Version” to V3.5 (The version we setup previously)
3. Set “MsBuild Build File” to the name of the demo solution: Jenkins-net-demo.sln
4. Click the “Save” button and you’ll be redirected to the Demo project page
5. Click the “Build Now” link.

You’re done!

This post is part of a series:

1. Jenkins.NET
2. Jenkins.NET Plugins
3. Setup Jenkins.NET
4. Setting up your first job
5. Your first build
6. Breaking the build
7. Diagnosing and fixing a broken build
8. Monitoring your build
9. Running your tests
10. Code Analysis
11. Security
12. Active Directory Security

• BONUS: Jenkins for .net in 5 Minutes

If you happen to be running Active Directory within your organization you can have Jenkins utilize it for authentication. This will save you and your team from having to remember yet another password when connecting to Jenkins.

Install the Active Directory Plugin via Jenkins » Manage Jenkins » Manage Plugins

Configuration

Tick the “Enable security” check box to open up the security area.

Access Control

Under the Access Control - Security Realm section select the “Active Directory” radio button.

Authorization

Under the Authorization section select the “Matrix-based security” radio button.

This option will give you the most flexibility over the security for Jenkins. I usually give Anonymous users Read access that allows me to share the build information with managers and stake holders if they are interested. As I trust my fellow developers I will usually give them Administrator access on the server. Of course you are free to setup whatever security Matrix you like, you can even take this as far as a project-based matrix.

• Enter your Active Directory username in the “User/group to add” text box.
• Click the “Add” button.
• Tick the Administer check box in the Overall area of the matrix.
• Finally click the “Save” button.

You have just given administrator access to this user, and they will be able to login to Jenkins using their Active Directory password.

Trouble shooting

If you find Jenkins is not connecting to your Active Directory controller, try setting the advanced settings for the Active Directory plugin.

Click the “Advanced…” button. To reveal the area where you can specify the full details of your Active Directory Domain and Server.

Start by setting the Domain Name of your Active Directory and clicking the “Save” button. Now retry your Active Directory access.

This worked first time for me but if your not so lucky, try the same process again with the Active Directory Domain controller setting.

This post is part of a series:

1. Jenkins.NET
2. Jenkins.NET Plugins
3. Setup Jenkins.NET
4. Setting up your first job
5. Your first build
6. Breaking the build
7. Diagnosing and fixing a broken build
8. Monitoring your build
9. Running your tests
10. Code Analysis
11. Security
12. Active Directory Security

• BONUS: Jenkins for .net in 5 Minutes

By default Jenkins is wide open to anyone who stumbles across your web server, depending on your circumstances you may want to enable Jenkins security and force developers and even guests to login.

Configuration

Jenkins security is configured from the main Jenkins configuration page which is accessed via Jenkins » Manage Jenkins » Configure System.

Tick the “Enable security” check box to open up the security area.

Access Control

Under the Access Control - Security Realm section select the “Jenkins’s own user database” radio button.

Un-tick the “Allow users to sign up” check box otherwise anyone hitting the site will be able to sign up for an account (if your enabling security my guess is you don’t want that).

Authorization

Under the Authorization section select the “Matrix-based security” radio button. This option will give you the most flexibility over the security for Jenkins. I usually give Anonymous users Read access that allows me to share the build information with managers and stake holders if they are interested. As I trust my fellow developers I will usually give them Administrator access on the server. Of course you are free to setup whatever security Matrix you like, you can even take this as far as a project-based matrix.

Add Administrator

• Enter your username in the “User/group to add” text box.
• Click the “Add” button.
• Tick the Administer check box in the Overall area of the matrix.
• Finally click the “Save” button.

First user sign up

If this is the first time you’ve setup a user on the server Jenkins will immediately ask for your user credentials.

• Enter your user credentials.
• Click the “Sign up” button.

You should see a success message from Jenkins saying you are now logged in.

Adding Users

You’ll want to add more users to the servers this is done via the Manage Users page. You can access this page via Jenkins » Manage Jenkins » Manage Users.

Create User

Click the Create User link to add another user.

You will now see the Sign up page.

Enter the credentials for the new user. Make sure you remember the username, as you’ll probably want to give the new user more than read only access to the server.

Authorization

After creating the user you’ll want to give them an authorization level. This is done via the main Jenkins configuration page, Jenkins » Manage Jenkins.

• Enter your username in the “User/group to add” text box.
• Click the “Add” button.
• Tick the Administer check box in the Overall area of the matrix.
• Finally click the “Save” button.

This post is part of a series:

1. Jenkins.NET
2. Jenkins.NET Plugins
3. Setup Jenkins.NET
4. Setting up your first job
5. Your first build
6. Breaking the build
7. Diagnosing and fixing a broken build
8. Monitoring your build
9. Running your tests
10. Code Analysis
11. Security
12. Active Directory Security

• BONUS: Jenkins for .net in 5 Minutes

Jenkins can run a series of code analysis tools after each build, this will help you monitor the health of your solution.

Compiler Warnings

Ideally your solution will have no compiler warnings and you can have your solution fail to build if the any warnings appear. I know in the real world this isn’t always possible, so we can utilize Jenkins to make sure the number of warnings do not get out of hand.

This is accessed via the Jobs configuration page, for our Demo job we click Jenkins » Demo » Configure. You’ll find the “Scan for compiler warnings” at the bottom of this page under the “Post-Build Actions” section.

Configure

• Tick the “Scan for compiler warnings”
• Click the “Add” button under the “Scan console log” area
• Select MSBuild from the Parser drop down list
• Click the “Save” button

Now when you carry out a build, you’ll get a compiler warnings section as part of your build report.

Warnings report

Here we have no compiler warnings so I’ll commit a warning to show the information Jenkins tracks.

We now have 2 compiler warnings and we can drill down for more details by clicking the 2 warnings link.

We can continue drilling and find the actual source file and line number causing the warning.

Trending

As well as the low level details Jenkins also gives us a Compiler Warnings Trend graph.

Your mission is to reverse this trend and keep your compiler warnings low or preferably non-existent.

Tasks and To-dos

Another sign of Technical Debt is lots of To-dos, hack, and fix-me comments in your code. Lets use Jenkins to monitor these type of comments. For our Demo job we click Jenkins » Demo » Configure. You’ll find the “Scan workspace for open tasks” at the bottom of this page under the “Post-Build Actions” section.

Configure

• Tick the “Scan workspace for open tasks” check box
• In the “Files to scan” textbox enter: */.cs which scans all C Sharp files for these comments.
• In the “Tasks tags” High priority textbox enter: HACK, FIXME
• In the “Tasks tags” Normal priority textbox enter: TODO, TO-DO
• Tick the “Ignore case” check box
• Click the “Save” button

These task tags can be anything you or your team use to indicate work that needs to be carried out in your source. When we carry out a build, we’ll get a compiler warnings section as part of our build report.

Task Scanner Report

Here we have no tasks, I’ll commit a few To-dos and Hack comments to show the information Jenkins tracks.

We now have 3 open tasks and we can drill down for more details by clicking the 3 open tasks link.

As you can see depending on the priority of the open task we get different color bars to indicate they severity.

We can continue drilling and find the actual source file and line number of the tasks.

Trending

As well as the low level details Jenkins also gives us an Open Tasks Trend graph.

This post is part of a series:

1. Jenkins.NET
2. Jenkins.NET Plugins
3. Setup Jenkins.NET
4. Setting up your first job
5. Your first build
6. Breaking the build
7. Diagnosing and fixing a broken build
8. Monitoring your build
9. Running your tests
10. Code Analysis
11. Security
12. Active Directory Security

• BONUS: Jenkins for .net in 5 Minutes

After building your solution the next task you’ll want to automate is the running of your tests. Jenkins comes with a multitude of test plugins so whatever test framework you’re using chances are you’ll be covered. To show how easy it is to add tests to a build we’ll add NUnit to our demo solution and have Jenkins run the tests every time we commit a change to the source repository.

Test Project Structure

Structure of the demo project is:

Tools\NUnit\bin contains the NUnit framework and runner.

The DemoTest project references the nunit.framework.dll from this folder. This enables the solution to be checked out and run with out any pre-installation requirements. This work great for Jenkins but its also a great way to setup your solutions, if you need to move to a new machine or if you have a new starter you just check out the solution and its ready to build and run your tests.

Execute any test runner

The build step “Execute Windows batch command” works with any test runner that has a command line runner. We will use this method to run the NUnit command line test runner in the Demo project.

Use the Demo » Configure link to access the configuration page, under the Build section click the “Add build step” button.

Select the “Execute Windows batch command” to add a new build step.

Under the “Execute Windows batch command” section enter the command:

• Tools\nunit\bin\nunit-console.exe src\DemoTests\bin\Debug\DemoTests.dll

• Click the “Save” button

This command is telling Jenkins the location of the NUnit test runner (Tools\nunit\bin\nunit-console.exe) and the location of the test DLL to run against (src\DemoTests\bin\Debug\DemoTests.dll).

This command will now execute the NUnit test runner after every solution build.

Failing Tests

When a test fails Jenkins will fail the build and show a red ball for the status of the project.

Now we know the build has failed but we don’t want to start digging through the console output to find the details of the failing test. Lets introduce another Jenkins plugin which will show details of exactly which test failed and why.

Plugin Setup

Use the Demo » Configure link to access the Demo jobs configuration page, under the Post-Build Actions section.

• Tick the “Publish NUnit test result report” check box.

• Enter the output of the NUnit test runner: TestResult.xml

• Click the “Save” button.

Run a build again to see the NUnit test report.

• Click the Demo » Build Now link.

Of course the build has failed again but that’s what we want. This allows us to see NUnit test report. To view the report click on the failed build in the Build History.

We now have a Test Result area that is showing 1 failure in the DemoTests.ProgramTests.Add namespace. That’s certainly easier than digging through the console output. The benefits don’t end there, if you click on the Test Result link we will get a more detailed report.

Here we get a pretty report showing the full details of the failure. We can drill down for even more detail using the link DemoTests.ProgramTests.Add.

This gives the error message from the test, a stack trace, the filename of the failing test and even the line number. You can’t ask for much more than that but there is one more benefit we can eke out of our test runner and that is our test history.

Test History

Once you setup the Unit plugin, Jenkins will track all your test results. This is a great way to keep an eye on the general health of your project. I’ve added a few more tests and commits to the demo project to show how the test history works.

As you can see the Demo home page now has a “Test Result Trend” graph showing the initial failing test, followed by anther commit to fix the failure then another 4 tests that were added. The graph shows at a glance that our Demo project is getting healthier on every commit. This is the type of graph we want to see in our projects.

This post is part of a series:

1. Jenkins.NET
2. Jenkins.NET Plugins
3. Setup Jenkins.NET
4. Setting up your first job
5. Your first build
6. Breaking the build
7. Diagnosing and fixing a broken build
8. Monitoring your build
9. Running your tests
10. Code Analysis
11. Security
12. Active Directory Security

• BONUS: Jenkins for .net in 5 Minutes

Unless you’re a glutton for punishment manually checking Jenkins after every build is going to become very old very quickly. Luckily Jenkins has several notification mechanisms to save you this manual task.

Email Notification

We can setup Jenkins to send an email notification whenever a build fails this save us having to check the server after every build, we can trust Jenkins to email us on failure. Jenkins will also send a notification email when the build returns to a working state.

Setting up email notification is a two-step process. First we give Jenkins details of the email server and second we set which email addresses to notify upon failure of a build.

Email Server Configuration

Email server configuration is done via the Configure System page. You get to the configuration page from the main Jenkins home page Manage Jenkins » Configure System. At the bottom of this page is the E-mail Notification section.

Chances are you’ll have a local SMTP server, if not you can use something like the Gmail SMTP server as shown here. Make sure you tick the “Test configuration by sending test e-mail” check box and then click the “Test Configuration” button to have Jenkins send you a test email, confirming your configuration is OK. Once you’ve successfully received an email don’t forget to click the “Save” button to save your changes.

Project Notification Email

Once you have the email server configured you can specify per project who to notify when a build fails. This is accessed via each Jobs configuration page, for our Demo job we click Jenkins » Demo » Configure. At the bottom of this page under the Post-Build Actions section is the E-mail Notification area.

• Tick the “E-mail Notification” checkbox.
• Enter a space-separated list of email address to notify when a build fails.
• Tick the “Send e-mail for every unstable build” checkbox.

If you really want to annoy the person who broke the build you can send them another email by ticking the “Send separate e-mails to individuals who broke the build” checkbox.

Finally don’t forget to click the “Save” button.

Unfortunately the only way to test this is working is to break the build, follow the instructions in section 6. Breaking the build to test email notification is working.

Your constant reminder

Email notification is great but I also like to have a constant reminder of the current build status. The best way I have found to do this on Windows is by using the Hudson Tray Tracker (read Jenkins Tray Tracker), which is available to download from http://code.google.com/p/hudson-tray-tracker/.

Once you download and install Hudson Tray Tracker you get a tray notification icon showing a constant reminder of the current build status. Initially the tray icon will be grey until you point it at a Jenkins build server.

• Right click on the tray icon to access the context menu.

• Click Settings to configure the software.

• Click the “Add server” button.

• Enter the URL and port of your Jenkins server.

• Click the “OK” button.

You will now see a list of projects on the Jenkins server.

Tick the Projects you would like to monitor. Here there is only our demo project but in reality you may have lots of Projects to monitor.

Once you have a server and projects setup, the tray icon will turn green to indicate a good build. That is assuming you have a working build. When the build breaks the icon will turn red and show a build failed message.

You can also use the software to open Jenkins on the build page of a Job by double clicking on the tray icon to open the list window.

Then double click on the Job your interested in. In this case double clicking on the Demo line will open up Jenkins on the Demo job page.

The teams constant reminder

A large screen in the development room can be a great way to give everyone on the team a highly visible, constant reminder of the current build status.

Jenkins has a Radiator View plugin that is designed specifically for this purpose.

https://wiki.jenkins-ci.org/display/JENKINS/Radiator+View+Plugin

This post is part of a series:

1. Jenkins.NET
2. Jenkins.NET Plugins
3. Setup Jenkins.NET
4. Setting up your first job
5. Your first build
6. Breaking the build
7. Diagnosing and fixing a broken build
8. Monitoring your build
9. Running your tests
10. Code Analysis
11. Security
12. Active Directory Security

• BONUS: Jenkins for .net in 5 Minutes

Last time we had a failing build with Jenkin’s showing a red ball to prove it. The first place to look when we have a failing build is the console output. You can get to the console output via the main menu on the left of your project page.

Console output

As the screenshot shows we get all the output from our build process and there is a lot of it! I’ve highlighted the actual problem which is the causing the build to fail, our missing dll.

This is the error your team mates will see when they check out and try to build your code.

Console “blindness”

When you first see the console output for your build it can be a little overwhelming, there is a lot of information packed into the output. Sometimes you look at all that information and you can’t see the wood for the trees, or the errors in all that output. I have seen people look at this output and they are blind to the errors.

Of course once you get used to looking at this output it becomes easier. To help you get over this initially a simple search to find all the errors listed on the page can really help. Simply search for the word “error” and your browser will help you see again.

You now have only a few places to concentrate your efforts in that sea of information.

To fix the problem we can simply add the missing dll and Jenkins will rebuild the solution and we’ll be back to green balls.

Next time we’ll look at the different ways to monitor our build and it’s failures.

This post is part of a series:

1. Jenkins.NET
2. Jenkins.NET Plugins
3. Setup Jenkins.NET
4. Setting up your first job
5. Your first build
6. Breaking the build
7. Diagnosing and fixing a broken build
8. Monitoring your build
9. Running your tests
10. Code Analysis
11. Security
12. Active Directory Security

• BONUS: Jenkins for .net in 5 Minutes

Lets break the build to see how Jenkins reacts. I’ll add a DLL to the project then “forget” to add it to source control; unfortunately I see this problem a lot when new developers join the team.

I see red projects

As you can see Jenkins now shows a red ball next to the Demo project. Also notice the slightly cloudy weather icon indicating all is not well with our project.

How’s the weather?

Jenkins uses a weather metaphor to show at a glance how a project is doing.

	No recent builds failed
	1 out of the last 5 builds failed
	2 out of the last 5 builds failed
	3 out of the last 5 builds failed
	4 out of the last 5 builds failed
	5 out of the last 5 builds failed (Yeah I know the icon is no different to 4, go figure.)

Obviously we want our projects to stay sunny and avoid the bad weather so next time we’ll discuss how to diagnose and fix a broken build.