Continuous Delivery Without Breaking Everything
What is CD and, especially, what is it not?
Image: Science in HD
Let’s start with one key fact: Continuous Delivery, though expanded from Continuous Integration, is not simply automating your code deployment pipeline like you automated your build architecture. Continuous Delivery is a shared business process, a contract between different members of product delivery to move software through stages to someone who will benefit, without blocking it or at best avoiding unreasonably long delays.
Automation applied to an inefficient operation will magnify the inefficiency.
Where were we ten years ago? At your organization, it probably looked something like this: long product release cycles leading to long development and testing cycles with lots and lots of value bundled up in massive code drops.
…followed by many smaller point releases to fix all the things that broke when you finally received validation from the real world - not just from internal testing or beta users. I’m sure it was really fun going back over six months of code to find the one change that broke the entire release 🙃.
This was MindTouch prior to 2012. We delivered software packages, available for system administrators to download and patch or upgrade our software running in data centers. Software-as-a-Service (SaaS) delivery became a near-term goal for us, as supporting our customers indirectly through their IT departments was becoming unmaintainable. We wrote the software, so we knew how best to deploy and run it!
However, long six-month development cycles were unsuitable for SaaS delivery and also under-leveraged one of the key business-benefits of SaaS: you can deliver value to your customers immediately.
Much of our software was not in an ideal state for the “high-speed, always merge to the main branch, the main branch is deployed to customers” style of software delivery. As a result, we approached SaaS development and delivery in a more cautious, though not entirely pure continuous model:
This is our current GitHub workflow. Yes, I know: Feature branches are not continuous. However, this is a transitional state for a codebase, which was until very recently tested end-to-end within six-month cycles, while its stabilized to be continuously delivered whenever it needs to be. For the time being, we’ve chosen weekly releases as our target. The immediate benefit achieved is a much smaller delta between changes resulting in quicker defect fixes (or rollbacks if necessary).
Rollbacks require that there is a previous feature branch or tag that we can rollback to - seemingly the antithesis of a continuous delivery process
Technically speaking, the long-term goal is to deliver value when it’s needed and not let the tools dictate when we can deliver.
A single branch that always flows into live production requires confidence that the process will be resilient as possible and can quickly deliver corrections to defects as well as new features or value
Test your Continuous Delivery process with humans first and make sure it works for how your organization needs to reliably deliver software today.