Friday 1 April 2011

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....

9 comments:

  1. This depends on the type of project you are working on, but in my field of work we often depend on firing up small tests and whatnot depending on GUI access. This makes the service option somewhat more complicated to use, since GUI access is pretty much restricted and you have to switch users or do other workarounds.

    Also, maintaining a container server like Tomcat etc, can give admins opportunities for configuring parts of the system like their regular web server, keeping knowledge transferable wrt basic setup, caching, mem usage etc.

    I maintain a Jenkins setup, building a mix of C++ and .NET projects (with loads of interdependencies), and we currently use Tomcat as the container.

    However, I can see the service approach you have chosen as a "more correct" way of running Jenkins on a Windows setup.

    Anyway, it's a breeze doing .NET with Jenkins, as we have builds, unit testing, code analysis and graphical tests running perfectly! Looking forward to following your Jenkins adventures :)

    ReplyDelete
  2. I've just installed Jenkins on my personal development machine - version 1.474. I simply ran the MSI and it installed Jenkins, the win service and started it all. DONE.

    ReplyDelete
  3. can someone share some settings or info on configuring a build job to build a .net app?

    ReplyDelete
  4. Hi Mahmood,

    Thanks for joining us.

    There are many settings and information about this in later posts. Keep reading.

    Please feel free to leave questions / comments.

    Cheers,

    Andrew

    ReplyDelete
  5. I'm still pretty new to Jenkins (I'm actually downloading it for the first time right now). Still, as for the bundled-JRE question, having one means it is the one Jenkins was tested with; this one version will work. The already installed version may not work otherwise. Personally I prefer manually installing JRE's and JDK's in a separate directory and configure JAVA_HOME's on a per-application basis, but "that's just me", I guess.

    ReplyDelete
  6. Thanks Luiz,

    I do this the same way. Create a JAVA_HOME directory and tell Jenkins where to find Java in the Configure Jenkins page.

    ReplyDelete
  7. Does anybody have used IIS as a servlet container with Jenkins ?

    ReplyDelete
  8. Jenkins being java based will not work just purely based on IIS

    ReplyDelete
    Replies
    1. Hi Viral,

      You're correct. The Jenkins war file has the jetty servet engine embedded within it.

      I recommend running it as a windows service.

      Delete