Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Video Enhanced Edition
This is known as the Deming cycle: plan, do, study, act. (link)
Ultimately the team succeeds or fails as a team, not as individuals. (link)
If creating application documentation is painful, do it as you develop new features instead of leaving it to the end. (link)
It should be possible for a new team member to sit down at a new workstation, check out the project’s revision control repository, and run a single command to build and deploy the application to any accessible environment, including the local development workstation. (link)
The repeatability and reliability derive from two principles: automate almost everything, and keep everything you need to build, deploy, test, and release your application in version control. (link)
Create a Repeatable, Reliable Process for Releasing Software (link)
Every time a change is committed to version control, the expectation is that it will pass all of its tests, produce working code, and can be released into production. (link)
Continuous integration detects any change that breaks the system or does not fulfill the customer’s acceptance criteria at the time it is introduced into the system. Teams then fix the problem as soon as it occurs (this is the first rule of continuous integration (link)
In software, when something is painful, the way to reduce the pain is to do it more frequently, not less. (link)
As long as this is true they will be surrounded with a lot of ceremony and nervousness. (link)
There are rarely checks of any kind applied to configuration information, particularly if that configuration information is typed directly into some console. (link)
One of the key principles of the deployment pipeline is that it is a pull system—it allows testers, operations or support personnel to self-service the version of the application they want into the environment of their choice. (link)
This executable code should be the same executable code that is deployed into every environment, whether it is a testing environment or a production environment (link)
The practice of building and testing your application on every check-in is known as continuous integration; (link)
If releases are frequent, the delta between releases will be small. (link)
Our software should be fit for its purpose. Quality does not equal perfection—as Voltaire said, “The perfect is the enemy of the good,” (link)
Software release can—and should—be a low-risk, frequent, cheap, rapid, and predictable process. (link)
Indeed it should not be possible to make manual changes to testing, staging, and production environments. The only way to make changes to these environments should be through an automated process. (link)
All aspects of each of your testing, staging, and production environments, specifically the configuration of any third-party elements of your system, should be applied from version control through an automated process. (link)
Different members of a cluster behave differently (link)
We are test addicts, and the extensive use of continuous integration and continuous deployment, as a means of testing both our software and our deployment process, is a cornerstone of the approach that we describe. (link)
One of the principles that we describe in this book is to use the same script to deploy to every environment. (link)
An automated deployment process is cheap and easy to test. (link)
Performing manual deployments is boring and repetitive and yet needs significant degree of expertise. (link)
There should be two tasks for a human being to perform to deploy software into a development, test, or production environment: to pick the version and environment and to press the “deploy” button. (link)
We also employed continuous integration, using a CruiseControl.rb server that ran dblatex to produce a PDF of the book every time one of us committed a change (link)
The time from deciding that you need to make a change to having it in production is known as the cycle time, and it is a vital metric for any project. (link)
Software release should be a fast, repeatable process. These days, many companies are putting out multiple releases in a day. (link)
You should also include a link to the identifier in your project management tool for the feature or bug you’re working on. (link)
Finally, storing the binary output of the build breaks the idea of being able to identify a single version of your repository for each application version because there may be two commits for the same version, one for source code and another for the binaries. (link)
One thing that we don’t recommend that you keep in version control is the binary output of your application’s compilation. (link)
You can then store whole environments, including base operating systems with configuration baselines applied, as virtual images for an even higher level of assurance and deployment simplicity (link)