Moving Towards Continuous Delivery One Commit at a Time

Amazon Web Services sign at conference

Last month, I attended the 2016 Amazon Web Services re:Invent conference with Jed Carr, TeraThink’s Director of IT.  I went primarily with a DevOps focus, trying to expand our continuous integration and continuous delivery (CI/CD) capabilities by picking up some best practices by a leader in the market.

While I did attend some excellent break-out sessions, the specifics of each could bear it’s own blog post, there was a singular idea that came up during every session, keynote, or chat around the coffee pot.

Software moves faster than ever.

Successful software delivery is no longer measured in years, quarters, or months. We measure it in weeks, days, and hours.  According to Puppet and their 2016 State of DevOps Report, high-performing IT organizations deployed 200 times more frequently than their low performing counterparts. So if you’re an organization pushing out quarterly releases, you’re trying to keep pace with the front-runners pushing out twice daily.

I attended a breakout session facilitated by Chris Munns, a Business Development Manager with AWS DevOps. In his talk, DevOps on AWS: Accelerating Software Delivery with the AWS Developer Tools, he states that the Amazon internal teams deployed 50 million times in 2014 throughout their various environments. That’s an average of at least one deployment initiated every second of the year.

These numbers are – in short – fantastic. But how do you achieve this pace?

Continuous Delivery Starts with Continuous Integration

Development teams have to walk before they run, and it starts with continuous integration. It’s easy to overlook this key fact. Unless you execute an automated build on every commit, it’s impossible to deploy each incremental change to production.

At it’s core, CI/CD requires only three things:

  • A version control system
  • An automated build pipeline
  • Agreement among the development team that CI/CD is the goal worth achieving

That agreement is the most important. This means that fixing a failing build immediately becomes the most pressing concern for a development team. But having this CI pipeline in place to build and test the software with every commit is job number one.

Having been in CI environments for years and implemented several automated builds, I know this is easier said than done. Failing builds can be difficult to triage and even more difficult to maintain team confidence. However, knowing that each and every commit is being thoroughly tested before it can reach master – steps designed to protect the baseline – and seeing the increased throughput between development and production, leads to a happier customer, increased job satisfaction, and a higher functioning team.

Amazon Web Services helps bring CI/CD that much closer. It gives any team the ability to provision the extra build nodes and environments it needs at a fraction of the cost of traditional infrastructure. You can spin up an Amazon EC2 instance, deploy the latest build, test thoroughly, and tear it down for cents on the dollar. You don’t have to commit any further. Bringing these costs down to manageable levels enables organizations to experiment and innovate without substantial investment of time or capital.

Looking Forward

2017 will be a huge year for DevOps and CI/CD. More development teams will look to streamline their processes and deliver software more rapidly. Are you delivering your software quarterly or monthly? Do you want to use your CI/CD pipeline and AWS to implement a solution? Reach out to me at via email or find me on Twitter and let’s start exchanging ideas.

[Editor’s Note: This post was originally published on the blog of Dominion Consulting. On November 1, 2017, Dominion Consulting merged with TeraThink and are now operating jointly as TeraThink. All blog posts migrated from the Dominion Consulting website have been updated to refer to ourselves as TeraThink.]