Until your pretty code is in production, making money, or doing whatever it does, you’ve just wasted your time.

The purpose of Continuous Delivery is to reduce the cycle time between an idea and usable software such that it’s approaching zero

We find that in general you should expect to spend about 50% of your time creating or maintaining automated tests.

You should build the capability for continuous deployment even if you never intend to do continuous deployment.

The primary goal of continuous deployment is not to deploy continuously. It is to be able to deploy continuously. Doing that requires a dramatic shift in mindset and practices. In addition to learning to create efficient and stable automated background deployment scripts, teams also need to learn to commit smaller amounts of higher quality work with better automated testing then they might consider possible. Learning to do that is the real value of continuous deployment.

We don’t make money out of finishing all our story points on time. We don’t make money out of writing new features. We make money by delivering quality software to customers! So I think that is exactly what we should all be focused on.

[…] if you are truly drinking the CD cocktail, you are really delivering lots of small, pointed changes that are easy to roll back and should not be able to introduce major, application-wide bugs.

Stress level of CD is MUCH lower than when we made big updates and had to hope that everything was just right since there’d be so much code to review in the case of a breakage.

Real artists ship.

what’s the smallest number of steps, with the smallest number of people and the smallest amount of ceremony required to get new code running on your servers?