Here you will find ideas and code straight from the Software Development Team at SportsEngine. Our focus is on building great software products for the world of youth and amateur sports. We are fortunate to be able to combine our love of sports with our passion for writing code.
The SportsEngine application originated in 2006 as a single Ruby on Rails 1.2 application. Today the SportsEngine Platform is composed of more than 20 applications built on Rails and Node.js, forming a service oriented architecture that is poised to scale for the future.
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.
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.”
Test suite passes
Code review sign-off
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.
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.
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.