In order to deliver small increments of quality products and services frequently, agile teams rapidly and safely integrate newly added code and other assets into a working version of the product which can be accessed by customers / users, without breaking anything which is already working. Continuous Delivery describes the principles, practices and tooling for doing this.

Aside from shifting quality left and applying a rigorous cultural focus on quality from the start, another key aspect of CD is to build and maintain a comprehensive suite of automated regression checks which run every time a developer tries to commit production code, and gives them fast feedback if their change would break something which already works. They can now adjust their code to ensure nothing breaks, including wrapping unit and other automated checks around their own code so that the same level of confidence can be passed on to the next developer wanting to make a change.

Deploying and Releasing

• Deployment is the distribution of all the required software assets for a working version of a product onto a server which can be accessed internally. In contrast, releasing is making a deployed version of software available externally, i.e. in production environments, to customers.
• The ability to release on-demand makes this so much simpler, and is strongly associated with better quality software as well. Not being able to do this is often partly caused by deployments being coupled with releases. In modern software development, deploying and releasing are separated so teams can ensure they always have a high quality, stable, working version of the product available to use and test internally, with all the latest features.
• There will often be impediments to this due to legacy technical architecture and stack, but a worthwhile medium-term goal is to be able to deploy your products continuously to production, or get as close to it as you can.
• CD (continuous delivery/deployment) requires developers to continuously (or, at least, very frequently) integrate their code into the main code branch (“master”). Features which are not ready to be consumed by the customer can be “toggled off” in production environments by anyone internally through a simple UI, and toggled on when ready. This enables releases to be done “on demand” and be a business/product decision/endeavour rather than a technical one.
• Next best (and a potential quick win) is to fix the release schedule for each product, i.e. enable releases to easily be made on a preferred cadence for the customer (e.g. monthly, weekly) containing whatever features are complete and ready to be consumed, rather than releasing when x scope is finished. Note, this scheduled rather than scope-driven approach to releasing is sometimes called a “release train”.