The Agile Architect

The Agile Act of Continuous Delivery

Agile teams deliver software often. Really agile teams deliver software on a continuous basis. Our Agile Architect explores the concepts and techniques behind continuous delivery.

• By Mark J. Balbes, Ph.D.
• October 24, 2014

I learned some of my best lessons about what not to do in software development from my first job in the industry. One important lesson I learned was how not to deliver software.

I was but a humble medical physicist working on SPECT imaging systems. A large part of the job was writing firmware to control the hardware and software to analyze the data. As you would expect, there was a lot of software. I was a member of a team of excellent physicists who spent our days implementing new algorithms to create better, higher-resolution images. But as physicists, we were pretty much all loners. This was not an agile team. But, being 1995, six years before the Agile Manifesto, I think we can be forgiven.

Our process to write code and deliver it to production was very simple. Each of us would check out the code base for our last release from SCCS. We would work in the code for months at a time, implementing our algorithms, making changes, fixing bugs, with nary a check in or commit to hinder our progress. In fact, we did not have commit privileges. When we were done with our feature, we would zip up our code, copy it to a network drive, and there it would sit until the person who was our configuration manager unzipped it, merged it to the repository and committed it. As you can imagine this never happened.  In fact, the network drive was filled with zip files from all of our hard work. The configuration manager, who was not a software developer, had no clue how to merge the changes. And with no automated tests, nor even manual test scripts, he wouldn't know if he did it right if he tried. Which he was smart enough not to attempt.

What Is Continuous Delivery?
Continuous delivery is the process by which software can be delivered to the users with high frequency, perhaps even multiple times per hour. Continuous delivery is an extension of the continuous integration techniques championed by the agile community. If we can automate building our system, then we can automate testing that build. And if we can automatically test a build, then surely we want to deploy it to a production-like environment to run our automated acceptance tests. And once we can automatically deploy to a production-like environment and run all of our tests to ensure there are no regressions in previous functionality and that all new functionality works as expected, then of course we can automate pushing to the real production system.

Continuous delivery depends on multiple factors:

• A high degree of confidence in the quality of the software.
• A high degree of confidence that the functionality being delivered is coherent.
• The ability to rapidly deliver updates to users without annoying them.
• Rapid feedback.

In order to accomplish these goals, the team has to commit to a highly disciplined approach to automating as much of the software development, quality assurance, packaging, releasing and delivery process as possible. Automation allows the team to commit new features and have the automated build system take the code from development, to staging, and to production without user intervention. Let's take a closer look.

Software Development
I've talked at length in my previous articles about software development techniques that ensure the creation of high quality code that meets the needs of the end user. I won't belabor the subject here but, more than ever, it is important to follow highly disciplined technical techniques like test-driven development (TDD), automated testing (including user acceptance testing) and continuous integration.

Software Quality
To truly practice continuous delivery, you have to minimize or eliminate the need for a person to intercede in the delivery process. This means that all tests that you want to run for a release have to be automated. This includes all unit, integration, system, user acceptance, scalability and backward-compatibility tests.

Software Value
Typically, a deliverable feature is divided up into individual stories, each providing user value but none by themselves serving as a minimal marketable feature. It's up to the team to figure out how to handle these situations. Of course, if you can make every story individually deliverable, that's the best solution. If not, there are standard code branching techniques and more advanced techniques like Branch By Abstraction for delivering a coherent solution.

Software Delivery
Once the software is written, built, and tested (automatically, of course), it has to be pushed to a production-like environment to run user acceptance and other tests. Depending on your technologies, your tool set will be different but they all have some form of scripting that allow for automated, repeatable deployments. By using text-based scripts, per the advice of the Pragmatic Programmer, they can be managed (debugged, branched, merged) just like you would your code.
For example, an application may use Chef to provision servers and a combination of Rake and Capistrano to define deployment workflows.

Once the tests all pass on the staging server, there's nothing to stop you from deploying to production!

Rapid Feedback
Everything we've talked about so far is predicated on the fact that the team has rapid feedback on the entire process. Just as continuous integration stresses rapid feedback on the build process, so too does continuous delivery for everything we've discussed.

Final Thoughts
Continuous delivery may be best suited to Web applications where an update to the server automatically updates all thin clients. For thick clients, you need a mechanism to automatically deploy changes. Beware, however of annoying your users by constantly forcing them to install manual updates.

I've only scratched the surface of Continuous Delivery in this article. To learn more, I recommend the book "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation" by Jez Humble and David Farley from Addison Wesley.