How to Use Jenkins CI to Deploy Liferay Apps (Part 2)

Jenkins allows you to setup a deploy only project that would deploy artefacts from another build project. A typical setup at Veriday would look like the following:

Project 1 – Build and Deploy to Dev 1

Project 2 – Build and Deploy to Dev 2

Project 3 – Deploy to QA1

Project 4 – Deploy to QA2

Project 5 – Deploy to Prod. 1

Project 6 – Deploy to Prod. 2

In my previous blog post, I discussed how we setup projects like 1 and 2, in the list above. In this post, I will discuss projects similar to 3,4 and 5.

App Deployments

Before we build to QA1, one of our release steps is to configure project 3 to specify where the build artefacts will be coming from. Suppose we are promoting the latest development build from Dev 2 to QA 1. In this step we perform the following three steps:

1. Match the SVN URL in Project 3 to the SVN URL in Project 2. This is important in case some build configurations were changed for that environment.
2. Pick Project 2 as the source of the built artefacts and choose the build number. Each project has multiple builds depending on its setup. For example, Project 2, being a Development build task, would have a new build every night.
3. We let Jenkins tag the current build in the SVN repository. This allows, in the case of emergency, fixes in production to perform the fix against the specific build that was released.

Deploying to different environments is a fast process, in this case. Instead of building code for deployment, you are just shipping the same application to a different environment.

The setup listed above has several benefits:

1. On build day (or night) your activities are usually limited to picking the latest stable build on QA. i.e. the one that everybody has tested and is happy to ship to customers.
2. Sometimes unexpected things happens. It is always a comfort to know that reverting to the previous application version is quick and easy. This would be done by picking the same build number you shipped to production the last time.

Depending on your Liferay project, a build may involve various types of deployments:

• Portlets
• Themes and Layouts
• Various libraries, either your own or 3rd party ones

For portlets, themes, and layouts that typically get deployed into the Liferay /deploy path you usually don’t require a restart for Liferay to pick up the changes. However, deployments to Liferay or Tomcat’s lib paths typically require a restart. Our Jenkins build needs to be aware of this. All of the nuisances are configured on our Jenkins’s build tasks and deploys the various projects into the right paths, and then restarts Liferay.

In our case, deploying Liferay apps to a new environment takes about 2-3 minutes.

But, what about database changes? We haven’t crossed this bridge yet and we run database upgrade scripts manually during a release. This is a bridge that we definitely plan to cross in the coming year so stay tuned for a future blog post about Veriday’s experience with this.