I have no doubt you have heard about continuous delivery concept by now. It is an extension of Continuous Integration concept all the way to your end users and clients. In other words, your software production line is a well-oiled machine that is always ready to release. A small caveat here, even though the concept is called continuous delivery, in practice, it is not a never-ending stream of bytes being spit out into the world. The delivery happens in a very short, discrete iterations (like in a Twitter stream, each tweet is a unique object).Side note: You might hear arguments about continuous delivery versus continuous deployment. While we can argue the meaning of “delivery” and “deployment”, for the intent of this article, delivery is having a production-ready software.
Continuous delivery has tangible benefits for the software development lifecycle. Frequent releases decrease the amount of code to be tested and validated. Bugs can be fixed before they become deeply entrenched; and users can provide immediate feedback. But before plunging down the continuous delivery rabbit hole, we must assess how it will fit within an established organization and delivery processes. It requires careful planning and automation.
Think of an assembly line with the conveyer belt. There are three station along the way: development, testing and delivery. Developers throw features onto the conveyer belt. Down the line, features are packaged into widgets, tested for quality and delivered to users. The conveyer never stops.
No matter how agile the process is, oversight and planning are still important. Agile <> Chaos. The job of planners is to manage the flow of features on the conveyer: what goes on the conveyer, in what sequence and where it is delivered. Planners could be comprised of any combination of team members who are qualified to establish the delivery plan for features. Planning process can be a variation of agile methodologies adopted to specific needs, as long as priorities and effort are included in the planning equation.
Continuing on the conveyer analogy, the formation of features into ready-to-deliver packages must be automated. Just like a physical factory relies on robots to automate certain tasks, we rely on scripts and tools; even more so as developers, the “inspired lazy” creatures that hate repetition. The continuous delivery process requires a large investment into automation in five key areas: code management, build management, implementation management, test management and environment management.
The typical process is: check in code, label or branch, build, unit test, provision test environment, run tests, deliver and roll back (must have an undo button just in case).
Code management is arguably the low-hanging fruit here. Many mature tools do a very good job of managing source code. Build management is also a relatively simple automation task. Note, that I also include unit testing into build management as unit tests require same level of attention as the tested code does. If you are practicing continuous integration, you should already have the right tools and processes in place.
Implementation, test and environment management areas are where things usually get complicated. There are many choices with varying degree of complexity. For tests to be meaningful they must be executed in the environment that is identical to production. In practice, test environments might come close to production, but not be identical due to complexity and outside dependencies. Environments must be set up and torn down. Delivery and roll back mechanisms must be established.
The world is changing at an accelerating pace. Continuous delivery is a manifestation of just-in-time mindset onto the software development process. It might not work for every project or every team. But it has certain benefits for SDLC if adopted with careful planning and with adequate investment in automation.
Continuous Integration by Martin Fowler
Continuous Delivery by Jez Humble and David Farley
Deploying the Netflix API by Ben Schmaus