Continuous Integration and Jenkins

I found this old draft post hanging around on blogger and it reminded me to a time long ago before CI servers were a part of my dev life, so I decided to post it...

Jenkins (formerly Hudson) is an open source continuous integration server and assists the development team by allowing us to easily integrate changes into our software projects from our source control with confidence. Jenkins can be automated to build, test and deploy any type of software automagically. Jenkins doesn't require bucket loads of learning before you start using it and it's very easy to set up. It's also super extensible and caters for a wide variety of programming languages/testing frameworks etc and there are a lot of plugins available - and I mean a lot.

Feedback is key. If Jenkins has any problems building, testing or deploying any projects it can alert the development team in a number of ways (e.g. through a GUI, email, twitter and many more). So as soon as the build or any tests fail we get alerted and the team react to fix those changes - it's never broken for long.

As you can imagine, once we made the effort to set up our software projects in Jenkins, it has improved our 'quality of dev life' dramatically. Automating the building, unit testing, integration testing and deployment straight to our staging environment for every check-in means we are more confident, less stressed and a lot more productive. Once happy with our staging environment we can one click an application release to live. So our application users are getting newer features faster than ever. Ignoring IDEs and source control, I'd argue a CI server is probably the next most fundamental tool in a developers tool belt.

Jenkins! How did we ever live without you?!

How Powershell Behaves with Errors in the Script

PowerShell has two kinds of errors; terminating errors and non-terminating errors

Terminating errors are the errors that can stop command execution cold. Non-terminating errors provide an additional challenge, as you need to be notified of failed operations and continue with pipeline operations. Powershell by default tries to continue when non-terminating errors occur. Something I don't want to happen when I call Powershell with my CI server to release software. If there are errors I want the script to stop and tell me what is wrong - not the script to continue and report that everything went OK.

$ErrorActionPreference is a variable that describes how PowerShell will treat non-terminating errors. $ErrorActionPreference has four self-explanatory options:

• Continue (the default)
• SilentlyContinue
• Inquire
• Stop

To exit your script with an error code (if an error occurred), you'll need to exit using the $LastExitCode variable. This variable returns a number that represents the exitcode of the last script or application, needed for your CI server to know if the script ran successfully. Here's a template for what I use with the Jenkins CI server...

$ErrorActionPreference = "Stop"

# Do something...

exit $LastExitCode

Anything else?

Well, yeah... $error is an array of all the errors that have occurred in the current session up to the number specified in $MaximumErrorCount. Also, $? is a boolean value that is $true if the previous operation succeeded and $false if it did not.

7 Ways to optimise Jenkins/Hudson

We've been having some 'difficulties' with Jenkins the past couple of weeks. This whitepaper from the guy that wrote most of the Jenkins core code looks like it could be interesting... 7 Ways to optimise Jenkins/Hudson.

Git First Impressions

So far, so good :) Took me just under half a day to set up a git repository, import the existing project source and update our CI server. GitHub works well for creating your repositories and walks you through the process. It's very quick, especially when you comapare it to TFS - it's knocked 40% off our build time for a fairly hefty web app. It's not just the speed thats impressive though, having a complete history and full revision tracking capabilities, not dependent on network access or a central server is something as a TFS slave user, I've been longing for. I still think there's lots to get my head round, which will make things interesting next week when I have some real work to do on this project; so watch this space.

Here are some useful resources if you are just getting to grips with Git:

• Git Homepage
• GitHub - repository managment
• Git for the lazy - nice and concise
• Handy help docs from GitHub - including generating SSH keys so you can upload to GitHub
• A useful Git cheat sheet

Git Bandwagon

I've being feeling the peer pressure of late to try out Git as source code repository for our the app team's projects. Today I'm going to give it a try with one of our bigger web apps. I'm hoping that it won't take me too long to get my head round the way Git works and that it results in the project build time dropping on our CI server. Well it had better - time is money!

Git is an extremely fast, efficient, distributed version control system ideal for the collaborative development of software.

ASP.Net allowDefinition='MachineToApplication' Error

I've come across this problem a number of times now and it was beginning to annoy me. A few times when building projects on continuous integration servers and today when upgrading my MVC web app to MVC 2 I hit the following error:

It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level This error can be caused by a virtual directory not being configured as an application in IIS.

Everytime I failed to figure out what the problem was and instead I had to admit defeat and use a work-around :(

Well the error message is quite helpful for some people getting this error at runtime and tells them how to fix the problem - configure the web apps virtual directory to be an application. However, I'd been stumbling upon this delightful error when compiling projects - not at runtime!

Luckily I had a light bulb moment... the compiler was not referring to my main web.config for the application, but instead was moaning about a web.config within a sub directory of my application (a backup of the project). Deleting the backup sub directory solved my problems!

I got 99 problems but my web.config ain't one!

Visual Studio Team Foundation Server Power Tools

I often forget to comment my check-ins and I'm getting fed up with having a big sign stuck to my monitor saying "Comment Your Check-Ins!". So I've decided to make use of Team Foundation Server Power Tools to enforce a custom check-in policy to ensure everyone checks in comments with their changesets.

Team Foundation Server Power Tools is a set of enhancements, tools and command-line utilities that improve the Team Foundation Server (TFS) user experience.

Other useful features of the add-on include the ability to enforce a 'testing policy' to ensure tests are run before check-in and an alert editor for enabling subscriptions to events (e.g. failed builds) in Team Foundation Server. A very useful add-on indeed :)

Hudson as an Alternative to TFS

I've been looking at alternatives to Team Foundation Server for my latest project's continuous integration tool... and I think I've found it!

Hudson was suggested to me by a colleague (Jonathan Relf) after his attempts with Cruise Control became a little frustrating.

You'll have Hudson installed and building your projects in under an hour unless you're stupid or get carried away with the large number of plugins, including a Chuck Norris plugin ;)

I particularly enjoyed...

• VERY easy to setup
• LOADS of plugins
• Setup, monitioring and configuration is all through a nice web based interface

I'll keep you posted with how I get on.