Continuous Deployment with LiveRebel
At Devoxx, I had an interesting chat with the guys from ZeroTurnaround on their LiveRebel product. LiveRebel is a Java EE server management tool, designed for making automated, instant updates to Java applications in production without server downtime. ZeroTurnaround had prepared a nice demo and I was really eager to try it myself .. on a real project.
One of the projects I’m currently working on, uses Jenkins as a CI server. Our applications are built in Maven and use Sonatype Nexus as a central repository. Post-build, we have Sonar integration. As I didn’t want my proof-of-concept to interact with our actual application server, I installed a new GlassFish 3.1.2 server. Just to make sure the application server didn’t interfere with the result, I manually deployed the WAR of the selected application first on the new GlassFish server. That part didn’t pose an issue.
After downloading the stable version of LiveRebel, I started the LiveRebel Command Center:
./lr-command-center.sh run
This results in a web front-end that can be used to easily configure servers and applications:
On that front-end, you need to select “Add Server” and select the platform you want to deploy on (GlassFish in my case). The web front-end will present an easy to follow guide on how to install the LiveRebel Java Agent: (lr-agent-installer.jar) for that specific platform. After restarting the GlassFish domain .. all is ready. It’s also possible to enable/disable the LiveRebel java agent:
lr-agent/bin/admin.sh [enable | disable]
which is interesting if you don’t want LiveRebel to be intrusive, after deploying. In the front-end, you can also generate an authentication token in the “admin”-menu. This authentication token will be used in Jenkins.
The only adjustment I had to make in my application was adding the LiveRebel Maven plugin to the POM of the application. The LiveRebel Maven plugin, takes care of making the liverebel.xml file. The liverebel.xml configuration file is used by LiveRebel to manage the application versioning and should be present in every application archive, including deployed applications managed by LiveRebel and archives uploaded to the LiveRebel console.
<plugin>
<groupId>org.zeroturnaround</groupId>
<artifactId>jrebel-maven-plugin</artifactId>
<!-- Optional configuration -->
<configuration>
<name>${project.artifactId}-development</name>
<version>${project.version}-${maven.build.timestamp}</version>
</configuration>
<executions>
<execution>
<id>generate-liverebel-xml</id>
<phase>process-resources</phase>
<goals>
<goal>generate-liverebel-xml</goal>
</goals>
</execution>
</executions>
</plugin>
After installing LiveRebel, I downloaded the LiveRebel Deploy Plugin for Jenkins. This plugin requires the LiveRebel authentication token. In my Project in Jenkins I added a “Post Step”: Deploy or Update artifact with LiveRebel. After selecting my new server I fired up a Jenkins build … And saw that my application was getting deployed to the new server .. and was working as expected.
I have to say that I was impressed with LiveRebel and how easy it was to get it all up and running with an actual application. Since it’s started from Jenkins, a lot can be configured: deploy time, naming, .. The LiveRebel web front-end makes it possible for Operations to do automated deploys if continuous deployment isn’t “possible/accepted” in a productive environment.
I made a small scheme to illustrate the final set-up of my proof-of-concept:
All of the steps now work automatically, without any manual actions. I haven’t looked into more advanced features such as database integration, rolling restarts or the possibility to maintain user sessions over deploys, but I’m intrigued to play with it more.