Notite Continous Delivery

Principles

1. Build quality in
Involve the customer early in discussions

2. Work in small batches

In continuous delivery, we try to get every change in version control as far towards
release as we can, getting comprehensive feedback as rapidly as possible.

3. Computers perform repetitive tasks, people solve problems

- The key goal is to take repetitive manual processes like build, deployment, regression
testing and infrastructure provisioning, and automate them. In order to achieve this, we need
to version control everything required to perform these processes, including source code, test
and deployment scripts, infrastructure and application configuration information, and the
many libraries and packages we depend upon.
An automated deployment process must be used by everybody, and it should be the only way
in which the software is ever deployed. Use the same script to deploy to every environment,
then the deployment to production path will have been tested hundreds or even thousands of
times before it is needed on release day. If any problems occur upon release, you can be
certain they are problems with environment-specific configuration, not your scripts.
The key to fast feedback is automation. With fully automated processes, your only constraint
is the amount of hardware that you are able to throw at thevproblem.

4. Relentlessly pursue continuous improvement

The constant discipline of pursuing higher performance by following the heuristic: if it
hurts, do it more often, and bring the pain forward.

5. Everyone is responsible

Nothing is “somebody else’s problem.” Developers are responsible for the quality
and stability of the software they build. Operations teams are responsible for helping
developers build quality in. Everyone works together to achieve the organisational
level goals, rather than optimising for what’s best for their team or department

6. Continuous Improvement
The whole team should regularly gather together and hold a retrospective on the
delivery process. This means that the team should reflect on what has gone well and
what has gone badly, and discuss ideas on how to improve things.

Why continuous delivery?

Low risk releases

Faster time to market
Higher quality
Lower costs
Better products
Happier teams
Create a Repeatable, Reliable Process for Releasing Software

DoD: Done Means Released - production or production like environment