When googling for what Continuous Delivery is, definitions that come up often explain CD as a set of tooling and systems that have been achieved. For example: code is deployed in an automated way, a Continuous Integration system runs tests on every push, and features use blue-green canary library for de-risking change being deployed.

Great! You have a pipeline, one-click deploys, and continuous integration set up. Does that mean Continuous Delivery has been achieved? Of course not. Achieving Continuous Delivery is a cultural mindset that must be adopted at all levels of the organization. Continuous Delivery is a contract that all engineers hold with each other about how the system evolves, and if that contract is broken by one, the whole system will break as a result.

For all the tools and systems associated with CD, their also exists the cultural mindsets needed to make that aspect of CD successful.

Continuous Integration

To ship change continuously quality and correctness of the application must be continuously verified.

• Engineers know to write tests to verify their code works, and to assure future engineers they don’t break their feature.
• Engineers will reject a merge request if it is missing tests, knowing they may change this code in the future and want to know when it breaks.
• Engineers who submit merge request without new or existent tests are not surprised or upset to have it rejected.

Small, Iterative Changes

Continuous Delivery avoids large deploys with system interdependencies and downtime requirements. It ensures that fixing breakages is fast and simple.

• Changes are implemented by each engineer in proper sequence to avoid “push and pray” situations, and ensure rollbacks are easy (or ideally, not needed even in an error situation). For example when building a new feature start with database schema changes, then deploy model logic and validations using those schema changes, then deploy API endpoints using those models, then deploy the frontend code changes using those API endpoints.
• Engineers are empowered to reject merge requests that are too large, or don’t follow proper sequencing.
• Engineers who submit large pull requests are not surprised or upset to have it rejected.
• Engineers reject merge requests that are too risky without a feature toggle.
• All engineers have permissions, knowledge, and freedom to manage all feature toggles.

Observability

Just like CI and deployments, Observability is a huge topic and gaining more attention every day. Observability must be at the core of every Engineer’s development practices and mindset. Assuming you have the latest APM, best logging, and a killer statsd setup:

• All engineers have access to system, application metrics and observability dashboards.
• Engineers who plan to make a change to a part of a system without observability add observability first.
• Engineers who submit merge requests with no metrics to measure the change are not surprised or upset to have it rejected.
• Engineers reject merge requests without already-existent observability.

Conclusion: Cultural Mindset

This is not all there is to CD. There are other important aspects, but all follow the same guidelines: Continuous Delivery must be the mindset shared by all and all must be trusted that they share and follow that mindset.