Building a Continuous Integration Environment in AWS

By Flux7 Labs
December 2, 2014


For several years, that’s been the challenge for both developers and businesses. And the pressure to condense the dev and test life cycle has only increased.

Andy Jassy at AWS re:Invent 2014 described the dev test cycle as a “flywheel that you can inject energy into that allows companies to be able to build more quickly for their customers.”

For businesses, getting the most out of those skilled developers with high salaries is key to successfully meeting customer demand, scaling and reaching new markets in an efficient manner.

Luckily, tools and capabilities to harness the power and functionality of the AWS platform have also improved. And thought leaders in various industries are sharing their own strategies that achieve rapid product development lifecycles.


And setting up optimized developer workflows has its practical challenges, including:

  • Establishing a full-production database

  • Managing cloud (AWS) dependencies

  • Trouble-shooting service addressing

The key, however, to efficient developer workflows rests in reducing the number of manual steps and preventing context switches as much as possible. This calls for continuous integration process and testing.

Creating a Continuous Integration System

Setting up continuous integration with Jenkins or CircleCI are well understood ways to implement the agility and process that continuous integration and delivery brings to a dev team.

By providing quick feedback to the developers from QA, as well as production, the developers not only become more productive, but also have actionable metrics. This can instill a culture of continuous improvement among the development teams.

For developers, an AWS-based continuous integration process adds agility. This approach allows them to experiment more and “fail” safely. They can commit code with less fear of breaking things. Frequent check-ins can reduce the time spent in merging branches.

At re:Invent, AWS announced a new service called AWS CodePipeline. It’s purpose is to serve the requirement for continuous integration.

For operations, new code is deployed in production as soon as it passes QA with Ops involvement. And, automated handling of code deploy can be achieved even in complex AWS auto scaling environments.

As of now, we have AWS CodeDeploy service, which aims to minimize the application downtime during deployments.

For example, consider a situation whereby one needs to deploy the latest code to a bunch of servers within an autoscaling group. Now, if these servers are running behind an Elastic Load Balancer (ELB), then manual code deployment without disrupting the service becomes difficult and prone to errors. AWS Codeploy can deploy the code to all servers at a time or to a small set of servers at a time.

It also provides various hooks so that one can automatically control the behaviour of ELB to not send the incoming traffic to those servers where deployment is still in progress. The primary advantage here is if something goes wrong during deployment, then the process is stopped and not propagated to the rest of the servers. This way, it will be easier to debug and rollback the deployment. It can also be integrated with most of the existing CI tools.

For CXOs, improved developer productivity means more value from staff that can come with high salaries. Continuous monitoring allows:

  • Better visibility into progress

  • Results in improved software quality

  • Leads to IT self service.

Additionally, clear progress metrics make it easier to present advancement to board members and other investors.

Did you find this useful?  

Interested in getting tips, best practices and commentary delivered regularly? Click the button below to sign up for our blog and set your topic and frequency preferences.

Subscribe to the Flux7 Blog