Deployment Automation

Continuous Deployment at FreeCharge Payments

We recently launched the FreeCharge Payments applications with autoscaling and continuous deployment. This post talks about how this was done and some of the choices that were made to accomplish this.

The FreeCharge web application goes through various lifecycle phases. We use Jenkins, Ant and Maven as our build tools and Ansible as our Continuous deployment tool.

Jenkins builds are triggered for each release version of the web application software (webapp). Jenkins then posts the successful builds to the Nexus repository. These builds are then propagated to the servers using Ansible.

The webapp is deployed on Amazon Autoscale Groups formed using Amazon AMIs which are created by running Ansible roles on them which deploy our tech stack software and configuration. Since the AMIs have all prerequisites inbuilt, the latency for the servers to be functional is reduced.  

Autoscaling brings in the problem of deployments on a dynamic inventory which is solved by the Continuous Delivery apparatus discovering if the servers have scaled up or down for an accurate point in time inventory. This is done by a python daemon script using python boto library.

In the above diagram ‘CD’ uses Jenkins and Ansible. Jenkins pulls code from git; generates a deployable; puts the artifacts in a versioned format in Nexus. Ansible runs a playbook on each of the servers categorizing them based on the Autoscaling Groups they have originated from.

The tasks performed by the Ansible playbook are:

  • Pull the artifact from Nexus.
  • Unregister the server from it’s ELB.
  • Stop the running services (tomcat, application service, any other monitoring service, etc).
  • Remove the old artifacts from the deployment directory of tomcat.
  • Copy the new artifacts to the deployment directory of tomcat.
  • Start services.
  • Register the server in it’s ELB.

After any deployment (successful or unsuccessful) a detailed email alert is sent to the Build & Release team using Amazon the SNS/SES services.

Conclusion:

Though there are many other options available for Continuous Deployment but we chose Jenkins+Ansible for it’s simplicity. Using this strategy, we have reduced our down-time between the payments app server deployments. The release process is just a “one-click” process now! At the end of the day our Dev and DevOps teams are happier, one of the very critical aspects that FreeCharge cares about!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s