Beginning with Jenkins and ColdFusion Part 2

It's been a couple months now since I blogged about getting started with Jenkins and ColdFusion, so I wanted to make a point of writing a follow-up. Automation is going to save me a lot of time, so it's time to get cracking!  

Since I'm working on a Windows machine (Win 7 to be precise - got a new laptop last month!), I follwed the recommendation on the website which was to download the native package. After extracting the .ZIP file to my desktop the installation was really straightforward:






After completing the installation and clicking the "Finish" button a new browser window opens which takes you directly to the Jenkins Dashboard - note the port 8080, not the same as ColdFusion (8500).


Voilà! Now to install a couple more plugins and we'll be ready to rock with continuous integration! As a side note I found it interesting that there's no database created.  I thought that was pretty cool, because I expected Jenkins to keep track of what it's doing in some sort of datasource.  It doesn't though.  It simply runs the scripts you specify, and the instructions you give it are stored in an XML file.  This post by Mike Christianson on Stack Overflow gives you the details if you're so inclined.

Since I'm using Github for source control I wanted to add the Github plugin to Jenkins. In my previous post I linked to a general Git plugin (which you can use), but I actually found it much easier to install the Github-specific plugin from within Jenkins itself.  Here's how that works:

From the Jenkins Dashboard, click the Manage Jenkins link, and then the Manage Plugins link (wow, that's intuitive!). 


Next, select the Available tab and type "Git" in the filter (top right).  You'll see the Github plugin as the fifth item on the list.  Check the box and click Install Without Restart.


Jenkins will install the plugin for you, all you need to do is make sure to check the box to have Jenkins restart after installing the plugin.


Jenkins will restart, and then your plugin is ready to go! Repeat these steps to install the Ant plugin if it's not already installed.


That's it for this time. Next time we'll look at how to use Ant to get Mr. Jenkins to do your evil bidding!

  1. Derek

    #1 by Derek - October 1, 2012 at 8:16 PM

    Hopefully not 2.5 months for the next one. ;-)
  2. Kris

    #2 by Kris - October 1, 2012 at 8:47 PM

    Yeah, my bad Derek. I'm working on the Ant blog now ;)
  3. Steve

    #3 by Steve - October 3, 2012 at 2:11 PM

    We also do CF and want to use Jenkins. However, I cannot find any information online that talks about developer workflow! The workflow and the theory is what I am missing. We use GitHub with SmartGit as our GUI. We check a file out of GitHub, work on it, check it back in... now what? What is Jenkins supposed to do and how is it supposed to do it? What if we want Jenkins to ignore the file we just checked in? Etc. Stuff like that.

    Your articles have been promising, thus far! Cheers.
  4. Kris

    #4 by Kris - October 12, 2012 at 2:29 AM


    Jenkins essentially just runs the scripts you specify. In my demo I'll be using an ANT script to give Jenkins directions. General work flow should be something like this: You'll have Jenkins periodically check your Git repository for changes (again, this is via the ANT script), and when it finds them it'll run any unit tests or selenium operations (tests). Once it completes those successfully Jenkins will move the file to your production server from your repository. That's it in a nutshell. I apologize for the time between posts, but between flying airplanes, keeping my clients happy, my family happy and preparing for my upcoming presentation at CFObjective ANZ I'm struggling a bit to post on my blog with decent frequency. I hope to have a follow-up sometime next week that will demonstrate this workflow in action and give you a decent base from which to work. Until then...
  5. Jim Priest

    #5 by Jim Priest - November 5, 2012 at 8:11 AM

    Like everything else in programming - there is no 'right way' to use Jenkins.

    It's very flexible so you can configure it how YOU want it.

    For us we have a strict deployment procedure so having Jenkins automatically deploy code to production is a no go. I'm working on setting up unit tests to run when ever a commit is detected (we're using SVN) and to run our cfSelenium based integration tests on a schedule (they take quite awhile to run).

    Failure sends an email to the dev who checked in the code. :)
(will not be published)
Leave this field empty: