How to use Jenkins CI to deploy Liferay apps (Part 1)

How to use Jenkins CI to deploy Liferay apps (Part 1)

Who is Jenkins CI?

Jenkins CI is an open source continuous integration server we use at Veriday to automate our builds and deployments to various environments. It is used at various companies including eBay, GitHub, Facebook, Liferay, Netflix, LinkedIn and many more. You can run your own instance in your office like we do, or even use a Jenkins cloud provider such as CloudBees.

We started using Jenkins CI about three years ago to produce nightly builds of Digital Agent so that our team could review and test the latest build of our product. Today our environment has grown to about a dozen servers compromised of development / integration instances, staging / testing instances, sales / demo instances  and finally, our production servers. All of the deployments to these environments are managed by our trusted friend, Mr. Jenkins, making most releases “minor events” that take a couple of minutes, and provide us the safety net of being able to roll back a release with just a click of a button.

Automating Builds

It starts with defining “jobs” for Jenkins to perform. These jobs can be automated or manually triggered. A job tells Jenkins what it needs to do. For example a “Build Job” would contain steps like this:

  • Check out the latest from an SVN branch
  • Build the code
  • Deploy it to one of the Liferay development servers
  • Restart Liferay
  • Notify the development team of any failures in the above steps

Our “Build Jobs” are automatic and happen overnight so that when we come in the next morning, we can review the latest on that development server. This year, we will also look at integrating our Selenium browser test cases into Jenkins so that with each build our UI test cases are executed and compared against the previous build.

One issue that we ran into while setting this up is that our Java application would build okay on our local environments but fail on Jenkins. Remember, on your local environment you have access to Liferay and Tomcat libraries that Jenkins would not necessarily have. To get around this problem we have a project in our workspace specifically for Jenkins that contains these “system” libraries. This project also contains configuration files for each environment that would contain paths to the Liferay home folder, IP addresses, the Jenkins user account to SSH, etc. Each Jenkins job would then define what environment the job is for ex. “DEV1”, “DEV2”, etc.

Adopting continuous builds is extremely beneficial to any software development team. I noticed the following three things on our team:

  1. Nobody wants Jenkins to send an e-mail saying their code check in broke the build – especially since the e-mail goes to the whole team. To avoid that, the team now always runs the builds locally and verifies it at least builds.
  2. We run several branches of development at the same time. At any time, we need to be able to review the status of the branch against the committed to tickets, enhancements, new features, etc. With our nightly builds, we can be sure that each of our development environments is up-to-date as of that morning.
  3. In the case that Jenkins does report a build fail, someone on the team (usually the first person) will spot the issue and make the correction the very next morning. Because of point (1) this is now usually a result of other reasons outside of the build itself. Ex. Jenkins ran out of space, or the target development environment was unreachable.

In Part 2 of this series, I will talk about how we use Jenkins to deploy our app on to Liferay using a build that was already verified and tested on a development server, and then on a staging environment, before the exact same build is promoted to production.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *