Automated Builds and Continuous Integration with Jenkins

The concept of an automated build is fairly basic, you simply take your existing build file (make, nant, ant, msbuild(.sln), rake) and set up a service to build it from your source control repository. 

Automating builds

Setting up automated builds provide a number of advantages:

1. Everything your project needs to build and run is checked into source control.
2. By scripting your builds you remove human error problems, computers are just better at running repetitive tasks
3. Logging what was done and when it was done.

At a former employer the marketing department needed to do content updates on a fairy regular basis; So they wouldn’t have to wait for us, I set them up with svn for the content directory and created some users for content deployment.  All they had to do was update the content and commit it and then deploy it.  We where happy because we didn’t need to spend time on their deployments, and they where happy because they could push content any time they wanted to.

Continuous Integration 

This is a key part of doing Test Driven Development, making sure your tests are run when checked in.  This makes sure that all of the tests are working in the build environment, and lets everyone know when there is a problem as soon as the build runs, and lets the developer responsible to fix it as soon as possible, creating an over all better code quality. 

Using Jenkins

Jenkins is an open source Build server forked from the Hudson project, basically when Oracle bought Sun/Java some of the Hudson team decided to was time to go their own way.  Jenkins Benefits from a log history of community support from it’s Hudson days allowing it to be a very mature and extendable system.  Having said that, it not as easy to use as some other build servers (see Continues Integration with TeamCity) but what it lacks in ease of use, it makes up for in versatility and flexibility.

User Management

Like most things in Jenkins User management is very flexible by default supporting LDAP, it’s own internal user DB, delegate to servlet container, and has a huge list of user management plug-ins for everything from Active Directory to GitHub OAuth.  Once the user is added you also have a fairly flexible authorization set up  from allowing anyone to do anything to completely locking it down. 

My biggest complaint here is that by default everything is wide open and the responsibility of locking everything down is placed on the administrator.

Build Jobs

By default Jenkins supports Maven2/3, completely rolling your own multi part build, and Monitoring an external job but  with a large selection of plug-ins supporting everything from rake to powershell to Fitness, to an Android Emulator.

Rolling your own multi part build is fairly strait forward if a little involved with a lot of the basic options you would expect like wither to keep old builds, how long do you want to keep them, how many do you keep, Quiet period, retry count, etc.

With it’s plug-ins your source control provider options are just about anything you can think of including:SVN, CSV, Git, ClearCase, etc. The same for build triggers by default it supports build after other projects, build periodically(nightly builds for example), pull scm, and remote triggering(call a url with an auth token to start a build).

When your done with your build you have built in support to ftp or ssh your build results with plug-ins to do everything from upload to Amazon S3 to the Appaloose Store for mobile apps.

The down side to all of this flexibility is you are forced to do a lot for the configuration your self, unlike TeamCity, if you want your code test results published you have to configure it yourself, if you want your code coverage results, you have to configure it to use something like PartCover yourself.

Reporting

Just as important as automating your builds is knowing what is going on with them, when are they running, did it fail, what failed, etc.  Jenkins has fairly nice tools built in to show you what is going on.  With a build history trend report, rss feeds, Email notification, and plug-ins to support everything from dashboard views to creating a Wall friendly display of all build jobs.

Conclusion

While not as nice to set up and manage as some other build servers, Jenkins is incredibly powerful with a lot of flexibly, and to be honest it’s really hard to complain about an enterprise level build server for free.  I would make the comparison between running Linux VS. Windows servers, Windows may be more polished but it’s not as flexible.