Continuous delivery principles

CD is an org-wide inclusive methodology that includes non-engineering teams like design, product, and marketing. CD encourages developers to focus on delivering the end-user product, whereas non-CD environments may incentivize “over the wall” behavior, in which the QA team becomes the primary user experience that developers are concerned with. The next sections will discuss specific principles that lay the foundation for CD workflows.

Organizational processes have their own development lifecycle. They usually start as manual checklists or “playbooks”, which are lists of tasks performed manually. Later they may be automated with software tools and scripts. Committing these playbooks to software scripts ensures that they are repeatable. If the checklist needs to be run again, a team member can execute the script. Reliability is gained when these playbook scripts are run consistently between environments. For example, the playbook for deploying code to a development or staging environment should mirror the production environment as closely as possible. This reliable consistency between environments and executions eliminates a whole class of consistency bugs.

Automation is a key value of CD. Human time is expensive and should be conservatively spent on creative exercises instead of tedious playbook task running. A manual process is not truly repeatable and reliable until it has been committed to code and is executable automatically on demand. Automated tasks can be composed together to create further levels of automation. Automate as much as possible: tests, releases, configuration changes, and more.

A cornerstone of CD, version control is an absolute must for any serious software project. Version control enables a team of developers to efficiently collaborate on a shared codebase. Git is the most widely used version control system and a great companion for CD. Version control enables ‘undo’ functionality by allowing rollbacks to previous release candidates. In addition to code; configuration, scripts, databases, documentation should all be version controlled to track edits throughout history.

In CD, quality is not an afterthought that is kicked to the QA team. Quality is baked into every step of the release pipeline. The central feedback loop of CD is a constant re-examination of the quality being delivered to end users. New features are delivered with sets of automated tests that ensure new code is bug-free and meeting quality expectations. Project planning for new feature releases should include considerations around analytics, performance monitoring, and automated testing instrumentation tasks.

Painful, time-consuming or error-prone tasks compound over time. Painful tasks should be addressed as soon as possible to prevent a compounding loss of energy. Imagine a painful chore that takes 20 minutes to do and is run five times a week. That compounds to a 100 painful minutes a week and ~400 painful minutes a month, etc. Imagine you could address this chore and optimize it to prevent the painful time altogether. Obviously, that would be a win.

“Do the hardest parts first” is also an exercise to help identify weaknesses in the organizational process. If there is a task that is procrastinated or actively avoided it is an indicator that it could be an area of improvement and should be actively pursued. Teams should regularly touch hard parts to stay familiar and keep them at the forefront of planning conversations.

The entire organization should be focused and incentivized to ensure the end user deliverable is as high quality as possible. Product Managers should plan with attention to deployment and quality assurance. The Security team should be actively involved in the release process. QA team members should test development and staging environments with as much rigor as they would on production to catch any failures before eventual release. Developers should actively be planning for production release.

Software companies are in business to deliver software to end users. There's no business if an app works solely on one developer's machine. “It works for me” is common red flag phrase that indicates a lack of awareness for the overall business goal and empathy for the end user. CD is entirely focused on shipping software to the end customer. Additionally, ‘done’ doesn’t mean when an individual team members contribution is done, but when the entirety of the team's contribution is complete.

Hopefully, the preceding sections have started to illustrate the high-level value adds of CD. At a macro level, CD promotes execution efficiency, cross team communication, product market fit, agility, and overall organizational transparency.  

At a micro level, CD can be instrumented with measurements of explicit tracking metrics. Some valuable CD metrics might be:

• Time from new feature design phase to production release.
• How many production bugs encountered by users.
• Level of user engagement on new features.
• The frequency of new feature releases

In addition, CD can be used as a foundation to build organizational performance metrics like KPIs. Finally, bottom line business revenue and financial health is a great way to measure the impact of organizational practices.

With an understanding of the benefits and philosophy of CD, the next steps are to implement it. A good starting point is continuous integration. Continuous integration or CI is the precursor to CD. CI focuses on automating the workflow of code release. It does this through the use of automated code testing tools and quality assurance tasks. Once CI is in place CD processes can be built on top of it to deploy code to end users, and develop a feedback loop which will steer future releases.