Welcome!

Welcome to the first instalment of the JenkinsHeaven blog.

Firstly, I would like to briefly explain why I decided to call this blog JenkinsHeaven. Two reasons:

1. In my opinion, compared to "grandfather Cruise Control" (or any other CI server for that matter), working with Jenkins is pure heaven.
2. NET + Jenkins = a match made in heaven (both "just work")

Hyperbole aside, thus the main focus of this blog is to show how to use Jenkins for .NET builds in a Windows environment.

Over time, post by post, I intend to share with you how to utilize Jenkins in a .NET environment.

Let's begin:

Jenkins Unlimited

While Jenkins is written in Java, it is not limited to being a Continuous Integration server for Java based systems. Not at all. What makes Jenkins so flexible is the plethora of available plugins. With the addition of a few key plugins, Jenkins can be used as a CI server for a pure .NET environment.

Installing Jenkins

I will assume that my readers are predominantly Windows-biased. While you COULD install Jenkins into a servlet container like Tomcat or Glassfish and optionally put it behind an Apache on Windows if you like and still use it for .NET CI by installing a few key plugins, I wouldn't recommend it.

12 months or so ago I would have, but not anymore. Recent releases of Hudson/Jenkins have made some key fixes around its restarting functionality and Windows Service support. At the time of writing this version 1.404 has just been released. Prior to these above mentioned key fixes I used to get Error reports every time Hudson restarted and also while running Hudson it would just randomly crash. These errors were emanating from hudson.exe. Happily I can report that these errors appear to have been addressed. I have not had another one for quite some time. I'll let you know in a future post if such errors reappear.As you may have guessed I am running Jenkins as a Windows service (on a machine running the latest JDK and .NET 4.5), which Jenkins supports very well out of the box. With its internal Winstone Servlet Engine, Apache and Tomcat are not required. Installation as a Windows Service is a breeze and provides bonus functionality to boot.

To install Jenkins as a windows service merely:

1. Download and install Java from the Sun website (if it is not already installed on the machine).
2. Set the JAVA_HOME environment variable.

That's the hardest part done.

1. Download the latest WAR file (from http://mirrors.jenkins-ci.org/war/latest/jenkins.war)
2. Execute java -jar jenkins.war from a command prompt.
3. Wait for Winstone to start up and navigate your browser to http://localhost:8080
4. Click on the Manage Jenkins link in the LHS menu.
5. Click on the Install as a Windows Service menu item
6. Specify a path (should not have spaces and should be succinct).
7. Click OK.

That's it. Its really easy. Now what's happened?

1. You will notice in the Windows Services Manager that a windows service called jenkins has been created.
2. Under Manage Jenkins > Configure System, the path you specified at step 6 is where Jenkins will put all its config files (including the WAR and its exploded form in a war subdirectory). For those of you who have been around Jenkins for some time (when it was called something else) you will recognise this as the "JENKINS_HOME" directory. However installing in this manner the "JENKINS_HOME" environment variable is not required. I don't have one on my machine at home and Jenkins has no issue.

What about that bonus functionality I mentioned? Well if you install Jenkins as a windows service in this way it is using Winstone as the container and therefore you can upgrade and restart Jenkins directly through the web interface. You don't currently get these extra buttons when running Jenkins inside another servlet engine like Tomcat or Glassfish.

Wait a minute...There's another option...

On Wednesday 23rd March 2011 (only a week ago at the time of writing) the world learned that starting from version 1.403, Jenkins is now available as an MSI. (http://jenkins-ci.org/content/windows-installers-are-now-available and http://mirrors.jenkins-ci.org/windows/). It also has a JRE and .NET 2.0 included in a setup.exe bootstrap.

Having tried this on a fresh machine I have to say I am pretty tempted to move over to this method of installation. Why then would you bother with the first option? Here are some possible reasons (I think) for staying with the "old way":

1. Installing via the MSI (or setup.exe) installs another JRE instance and puts it in a (new) "jre" subdirectory in the Jenkins install directory. Why have another jre if you already have a JDK installed (which contains a jre itself)? - Assuming you have a JDK installed already.
2. In the Windows Task Manager I see that the java.exe seems to be even more of a memory hog than under the first option.
3. The first option is still very easy.

Has anyone else out there experimented with both options? Is there a clear winner? Are we all going to be installing via the MSI from now on?

Next time: Installing plugins.

Special thanks to Bruno Kinoshita for encouraging me to create this blog.

Come visit my other site at fullcirclesolutions.com.au. All my best ideas are distilled into commercial tools and made available for purchase.

Till next time....