How to Configure and Use Jenkins - A Continuous Integration System

Jenkins (http://jenkins-ci.org/) is a Continuous Integration system, facilitates continuous build and test setup for projects. It is an open source tool is similar to 'CruiseControl'. Jenkins is quite stable tool and is used by many Organizations. In this article, we shall discuss about Jenkins, its usage, and configuration.

When we call it 'Continuous Integration System', what is this?

When we work in a team environment using some Source Control / versioning tool, we checkout the work code from repository and starts working on it. After this, every developer used to commit her code to repository whenever she is finished with her work. When application is highly integrated, every commit may change the application integration scenarios, break the integration and probably can induce bugs also, or can break the code compilation etc. Now we need some tool to ensure that we check this inter-dependencies of integration and the stability of latest committed code, as soon as any body commits the code. So we need some tool, which can perform following kind of tasks:

1. As soon as, any code is committed to source code repository (or at any given schedule), tool takes the update from repository for the project and run its build
2. Frequency to check any new commit in source code repository should be configurable
3. Build system is designed by team and can be based on any building mechanism like ant or maven. Tool should recognize and support the famous build tools like ant or maven etc
4. Tool builds the project and hence all tasks configured with build system will be performed
5. If build fails, tool should capture the 'build logs'/'console output' and should be able to send email with all logs to more than one configured email id
6. It should have some User Interface where user can be able to see the status of various projects, their last build time, failure, logs etc
7. If build passes, it means everything is good with new commit
8. Then tool should be able to check if any other project or module is dependent on current project. If yes, it should trigger the build for that project also
9. Again controls goes to step 5 for new dependent project
10. .....

For more information about 'Continuous Integration', please refer to

• http://en.wikipedia.org/wiki/Continuous_integration
• http://martinfowler.com/articles/continuousIntegration.html

Jenkins support all of above features and even more with different extensions.

Earlier 'Jenkins' was known as 'Hudson'. It was started by its founder (as Hudson) developer while working with Sun Microsystem. Later, it was separated out under a separate name as 'Jenkins' due to some IP (or similar) rights conflicts. Hudson is moved to Eclipse Foundation now. You can find it at http://hudson-ci.org/

After knowing this, one question come to mind is, which tool we should use? Well, this is something everyone need to find herself. However, we have decided to go for 'Jenkins' because it is where most of the original developers and community is working. It is having quite active development releases and is going well as of now. You can find more discussions at http://stackoverflow.com/questions/4973981/how-to-choose-between-hudson-and-jenkins

Jenkins is quite good, as:

• Its UI is quite good, simple and easy to understand
• Configuration is very easy. You need not to go to XML files for configuration, rather most of the things are available on UI
• Jenkins provides a dashboard to track all the configured jobs and it refreshes automatically after every few seconds to show the updated status of jobs
• Jenkins supports all the desired features of CI tool as specified above
• Jenkins can be extended by witting the plugins/extensions
• Jenkins provides permanent links for many of its pages, like for "latest build" or for "latest stable build". So these static links can be shared easily with stakeholders.
• It can distribute the build load to multiple machines and hence can utilize power of more than one machine in case if application is quite heavy
• It can keep track that which jar is produced by which build, and which jars were used in a particular build. So it can help in dependency management also.

Please refer to https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkinsfor reading the basics of Jenkins.

How to install Jenkins:

• Ensure that you have JDK 1.5 or later installed on the system 
• Jenkins can be installed either using its war file distribution or by installing it using installation packages for different platforms
• For war
• Download the war file of Jenkins from http://mirrors.jenkins-ci.org/war/latest/jenkins.war
• Install any servlet container like Tomcat (or JBoss etc)
• Deploy the war file to container
• War will be exploded automatically and Jenkins will be available at http://localhost:8181/jenkins/ (change host and port as per your configuration)
• If you want to run the Jenkins automatically as soon as system starts, you need to configure Tomcat as service (like in windows)
• Then as soon as Tomcat will start, Jenkins will start automatically
• For Installation packages
• Download the Installation package for your operating system from http://jenkins-ci.org/
• Unpack it and run it
• It will install the Jenkins and will also configure it as service (like on windows)

You can find various case studies for Jenkins installation at the bottom of following page: https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins

Jenkins Configuration:
Jenkins can be configured completely using User Interface. But it is good to understand how it works.

Jenkins keeps all of the configuration and runtime data in a directory configured as 'JENKINS_HOME'. Jenkins home cane be configured as

• Set "JENKINS_HOME" environment variable to the new home directory before launching the servlet container.
• Set "JENKINS_HOME" system property to the servlet container.
• Set JNDI environment entry "JENKINS_HOME" to the new directory.

Interesting point is, you can change the location of Jenkins home anytime. What you do, simply shut down the Jenkins server or service, move the contents of Jenkins home to new location, and change the Jenkins home, as defined above, before starting the Jenkins again.

Here is the Jenkins Home Structure from Jenkins documents:
-----------------------------------------------------------
JENKINS_HOME
 +- config.xml     (jenkins root configuration)
 +- *.xml          (other site-wide configuration files)
 +- userContent    (files in this directory will be served under your http://server/userContent/)
 +- fingerprints   (stores fingerprint records)
 +- plugins        (stores plugins)
 +- jobs
     +- [JOBNAME]      (sub directory for each job)
         +- config.xml     (job configuration file)
         +- workspace      (working directory for the version control system)
         +- latest         (symbolic link to the last successful build)
         +- builds
             +- [BUILD_ID]     (for each build)
                 +- build.xml      (build result summary)
                 +- log            (log file)
                 +- changelog.xml  (change log)

Back and Restore is quite simple in Jenkins. You simply need to backup the Jenkins_Home. Whenever you want to restore any backup, simply replace the backup 'home' data to the current home path.

Find more administrative options at https://wiki.jenkins-ci.org/display/JENKINS/Administering+Jenkins


How to use Jenkins
Using Jenkins means to configure the jobs for various projects, so that Jenkins can build these projects on various triggers. Here we are describing how to create/configure a job.

1. Go to Jenkins home page using the Jenkins URL on your system
2. Use Jenkins menu and opt the 'new job' option
3. Specify the Job name here
4. Choose the Job type from given options as per your project requirement. Like for ant based project, you can opt the first option as 'free style software project'
5. You can also create the new job by copying any existing job. For this, select the 'Copy existing job' option and specify the name of existing job
6. Submit the request and Jenkins will present you with a page to configure the new job. 
7. If job is created by copying any existing job, you will find various fields already filled. You need to update these as per new job configuration.
8. If job is created fresh, you will get the configuration page with all blank fields
9. Various fields and options are: 
1. Description - fill it for description of current job
2. Some other configuration options like whether build need parameters or not. If yes, UI will present you the option to specify the build parameters
3. Then you can specify the settings for Source Control / Versioning system
1. Select the type of tool you are using like CVS, or SVN
2. Specify the Repository URL for current job. For example, if you are building the project > trunk, ensure to give the repository URL till the trunk of the project
3. Specify the local system directory, if you want. Otherwise, it will be checkout to the default directory set up by Jenkins. 
4. Specify checkout strategy. This can be like, update the source code, or check out the fresh copy etc
5. You can specify the repository browser if you have configured anyone like 'Fisheye'
4. Then you can configure the build triggers. Build Triggers are the events when this job should be activated or run. 
1. You can configure to build this project after any other project is built. It is useful if current job is dependent on any other project.
2. You can configure to build periodically based on any given schedule. 
3. You can configure to poll the SCM on a given schedule and trigger the build if code is changed.
5. After that, next configuration will be for build system. Configure how build system should be invoked based on the build system used in project.
1. You can choose from given options like 'Execute Window Batch Command', 'Execute Shell', 'Invoke Ant' or 'Invoke Maven'
2. Suppose if you have selected 'Invoke Ant', Jenkins will facilitate you to specify Ant file name, build target and other advance options also like Java Options and Properties etc
6. Next step is to configure Post Build Actions, i.e., any event which you want to trigger once the build is done
1. There are various options available here. Two good options are to send the email with results to given email ids, and to trigger any other configured job.
2. Triggering of any other job is particularly important in dependent projects. You can start building any other dependent project, as soon as, current project is built. This option enables the use case to configure muliple inter-dependent projects.
10. Save the configuration and you are done.
11. Jenkins will trigger the job at given schedule by you and will email you the results if you have configured it to do that.

You can find various best practices about Jenkins at https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Best+Practices

There are many advance tasks also which can be achieved with Jenkins, like 'File Fingerprinting' to track the dependencies, and distributed builds etc. Please refer to Jenkins documentation for more details at https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins.

If you like the article, you may contribute by:

• Posting your comments which will add value to the article contents
• Posting the article link on Social Media using the Social Media Bookmark bar
• Connecting with 'VedantaTree' on Facebook (https://www.facebook.com/VedantaTree)

People who read this post also read :