Jenkins Continuous Integration

Continuous integration, or CI, is one of the hottest topics in web application development today. There are a myriad of reasons why you should be using CI and even more ways to implement it in your organization. For those who aren’t familiar with CI, it is the process by which incremental changes in version control are frequently and automatically built and tested for defects, thereby eliminating the integration phase of development. This fosters a more rapid and reliable development cycle by ensuring that any errors that crop up will be quickly identified and resolved well before the code is sent to QA or production. For a more in-depth look at this topic, see Brent Lemons’ blog post on Continuous Delivery.

I’m Convinced. Now what?

So, you’re on board with the benefits that CI can bring to your development process and all you need to do now is implement it within your organization. Continuous integration and delivery are, in theory, highly automated and customized to your particular environment. If you’re developing a larger web application, you probably have multiple environments for testing and integration, along with environments for production and local development. Keep in mind that all of these need to be covered by the continuous integration process. In order for this to be successful in a complex environment, like the one just described, quite a bit of work is required to set up things like automated builds, testing, and deployment. Fortunately, the Jenkins continuous integration server has already solved all of these problems for you.

Jenkins To The Rescue

Jenkins CI (http://jenkins-ci.org/) is an open-source, Java-based continuous integration server that is able to manage and automate your entire build process from compilation all the way to production deployment. Based on the Hudson CI server, Jenkins has a large, vibrant community built around it with active code contributors and updates being delivered frequently. It is easily customized to fit a specific development environment with a myriad of available plugins, and is easily extended if a plugin doesn’t exist for a particular configuration.

Now, we’ll walk through a simple real-world example, with the assumption that you have a standard Spring MVC project built with Maven and stored in a version control system like Git either locally or remotely on GitHub.

Download & Install

Downloading and installing Jenkins is a fairly straightforward exercise and starts with a quick download of the Jenkins CI server, which can be found here. Jenkins CI, by default, is packaged as a standard WAR file, but can also be pulled down as a standalone server for whichever operating system you want to install it on. Jenkins can be deployed to any servlet container. For now, we’ll use the web server that comes bundled inside the Jenkins WAR. To start it, simply run “java -jar /path/to/jenkins.war”.  Once Jenkins is started, open a browser and navigate to localhost:8080. You should see something like this:

From here, you can download any of the 400+ plugins developed by the Jenkins community. Jenkins comes with a wide assortment of plugins pre-installed, but you will most likely need to install a few to support your particular project configuration. For this example, you will need to ensure that the Maven, Git, GitHub, and Deploy plugins are installed. Once all the plugins are installed, navigate to Manage Jenkins => Configure.

Most sections look like this one and for the most part are self-explanatory. If anything holds you up, there is documentation available at jenkins-ci.org. For this example, configure Jenkins to either automatically install or use local versions of Maven, Git, and the JDK. Once these tools are in place, you’re done configuring Jenkins and are ready to run jobs on the server.

Continuously Integrate

With configuration finished, you’re free to create a new job to build, test, and deploy our example Spring/Maven project. Navigate back to the home page and then to “New Job”.

Our example utilizes a remote Git repository hosted at GitHub. Configure Jenkins to point this job at your remote repository and select “Build when a change is pushed to GitHub” as your build trigger.

Fill in the location of the WAR file created by Maven after the build and test phases, the context path, container type, and the manager credentials for your container to allow Jenkins to automatically deploy the WAR. With this work complete, you should be ready to try out your new job. Scroll to the top of the page and click “Build Now”.

You can always start a job at any time by clicking “Build Now”.  However, we have set up this job to start whenever a push to GitHub is detected. This is done via SCM polling or GitHub service hooks.

With service hooks set up, all you need to do to trigger automated builds, tests, and deployments with Jenkins is to simply push changes to your remote GitHub repository.

Wrap Up

Congratulations on taking your first steps into the world of CI. As you can see from our real-world use case, Jenkins is an incredibly versatile and complex tool, capable of handling a myriad of environment and project requirements. Setting up continuous integration within your organization can be a daunting task, but hopefully this brief introduction to Jenkins CI will greatly simplify that. Copious documentation is available online for everything covered here. For a deep dive on Jenkins, stay tuned for a future white paper by Brent Lemons.

Curious to learn more about Credera’s Java experience?  Contact us or visit our Technology Solutions overview for more information.

• Open Source
• Jenkins
• Continuous Integration
• CI
• Web Development