Coding in the Crease

Continuous Delivery as described by Jez Humble is the ability to get software changes to users or production “safely and quickly in a sustainable way.” The ideal team has a comprehensive test suite at the unit, system and user-interface levels. The ideal team deploys code changes one at a time, automatically kicking off a deploy when code is merged.

SportsEngine doesn’t match these ideals and we have been successfully reaping the benefits of Continuous Delivery for over 6 years. Our test coverage ranges from 50-90% with definite areas that need improvement. We branch frequently, once or more per Jira issue, but have only one long running branch. We deploy multiple code changes together, although anticipate improving to single code change deploys in the near future.

The key challenges to starting Continuous Delivery are not technical, but instead are about how people work together when developing software. Changing how a team works and how individuals work throughout their day is the hard part. Here are three steps to get started.

Steps to start Continuous Delivery

1. Establish the criteria that all code changes must meet prior to deploy.
2. Ability to deploy on demand reliably.
3. A team that actually codes small.

Establish the criteria that all code changes must meet prior to deploy

The first step is about agreeing amongst your team what criteria must be met prior to deploying an individual code change to production. The following have been successfully in use at SportsEngine for 6 years and is a great starting point. These steps represent your deployment pipeline, which Dave Jabs nicely summarizes as “a delivery pipeline through which new software can continuously flow, and as it flows, it is validated to progressively higher levels of quality.”

1. Test suite passes

   • Never deploy code when the test suite is failing.
   • If you don’t have a test suite or you have one with very little coverage, you can still get started with Continuous Delivery. Ensure the basic structure is in place so developers can build and improve the test suite over time.

2. Code review sign-off

   • We always want to know that at least 2 people think the code is well written, maintainable, high quality, secure, etc.
   • Any developer on the team can do this.
   • A successful and positive code review process is key to developing a Learning Culture.

3. QA sign-off

   • We always want to know that the code change about to be deployed has been manually tested on a production-like environment. Infrastructure as code type automation is necessary to maintain a production-like environment well.
   • Anyone on the team can do this. Ideally QA Engineers if available.

Ability to Deploy on Demand Reliably

There is no need to over do this step initially! If a deploy can be triggered in a few minutes with a handful of steps this is sufficient. Deploys should not cause downtime of course!

On a daily basis, whoever does deploys on your team simply checks the list of code changes ready for deploy, verifies manually that they meet the criteria agreed upon (test suite passes, code review and QA sign-offs present), and then executes the deploys. Once your team is doing continuous delivery the deployment automation can be improved over time.

A Team that Actually Codes Small

It doesn’t matter if your team is able to do Continuous Delivery if there isn’t anything to deploy! Getting your team to code small is the hardest and most important step. Coding small is all about breaking problems down into small pieces and driving these small pieces through your pipeline for feedback. Coding small is a skill that must be learned, practiced and improved over time.

In October of 2016 I presented these concepts at Agile Day Twin Cities. This was a multiple track conference and there were around 100 people at my presentation. I surveyed the crowd on the frequency of deploys within their teams and was surprised at how few teams are doing this.

• deploy once every 3 months - about half the crowd raised their hands
• deploy once a month - about half the crowd
• deploy once every 2 weeks - 2 or 3 hands
• deploy daily - 2 hands, one of which was mine

If your team isn’t doing Continuous Delivery it is time to get started. The technical challenges are easy. Put the basic structure in place, get started and improve over time.