Continuous Delivery

Being able to deliver features to customers quickly is an incredible capability in the modern consumer-driven world. With implications across team culture, practices, and technologies, continuous delivery is a organizational approach to software development that enables changes made to production through safe, quick, and sustainable processes.

"Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way." Jez Humble

Jez Humble and Dave Farley spearheaded the efforts around the philosophy and implementation of continuous delivery, and have laid the foundations of its principals and technical practices in their book Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. The driving goal of continuous delivery is that the application is always in a releasable state. In order to acheive this, there are multiple principals to consider.

• Build quality in instead of testing for quality later.

• Work in small batches by committing incrimental code changes frequently.

• Computers perform repetitive tasks, people solve problems. Let computers package code and run tests while engineers create solutions.

• Relentlessly pursue continuous improvement through automated, insightful feedback mechanisms.

• Everyone is responsible. Share knowledge, reduce blame, and swarm on issues.

Configuration management

Reproducibility: We should be able to provision any environment in a fully automated fashion, and know that any new environment reproduced from the same configuration is identical.

Traceability: We should be able to pick any environment and be able to determine quickly and precisely the versions of every dependency used to create that environment. We also want to to be able to compare previous versions of an environment and see what has changed between them. (source)

Continuous integration

Code should be broken down into small batch work and integrated into the mainline branch daily and create a deployable artifact from the build pipeline. Long-running branches and unmerged code act as technical debt that increase feedback cycles and decrease flow with added merge conflicts.

Continuous testing

Testing should occur through the automated pipeline process, including unit tests, code quality scans, acceptance tests, functional tests and non-functional tests. Utilize tools and computing power to automate repetitive tasks to provide quick feedback on the application's quality.