DevOps Culture - The Practice of Cloud System Administration - page 189

Whilemostoftheseprinciples areself-explanatory,itisworthwhileexpandingonthethird
principle. Often our response to error-prone, painful, and difficult tasks is to find ways to
do them less often. Continuous delivery says to do them more often to improve our skill
(“Practice makes perfect”), fix the problems in the processes, and automate them.
There are also four practices of continuous delivery.
The Four Practices of Continuous Delivery
1. Build binaries only once.
2. Use the same repeatable process for deployment to every environment.
3. Do basic functionality tests (“smoke tests”) on your deployment (e.g., include dia-
gnostics).
4. If anything fails, stop the line and start again.
For any given release cycle, binary packages are built only once. Contrast this with envir-
onments where QA builds a package and tests it, and then deployment checks out the same
codeandbuildsthepackagetobeusedindeployment.Notonlyisthisduplicationofeffort,
buterrorscanalsocreepin.Multiplebuildrequestsmaybeconfusedormiscommunicated,
resulting in packages being built from slightly different source code revisions each time.
One team may be tempted to “slip in a few small fixes,” which might seem helpful but is
dangerous because it means some new code did not receive the full, end-to-end testing. It
is difficult to verify that the second time the package is built, the same exact OS release,
compiler release, and build environment are used.
Version-Controlled Builds
At one of Tom's former employers, the build system checked the MD5 hash of
the OS kernel, compiler, and a number of other files. The build tools team would
determine that version x.y was to be built with a specific tool-chain and the build
system wouldn't let you build that version with any other toolchain. If a custom-
er five years later required a patch to version X, the company knew it could build
the software exactly as needed with only the patch being the different item, not the
compiler, OS, or other tool. This was particularly important because the company
made software for designing chips, and chip designers didn't change toolchains
onceadesignwasstarted.IfyoustartedadesignwithversionX,thevendorprom-
ised it could fix bugs in that specific version until your chip design was finished.
By automating as much as possible and creating documented processes for steps that
cannot be automated, we create a repeatable process for deployment. In a traditional soft-