CI/CD & DevOps Practices Practice Question 6: Build Once Promote
CI/CD & DevOps Practices · Test 1 · question 6 of 10
A pipeline has three stages: test, staging, and production. Each stage checks out the same Git tag and builds its own container image, and each image has that environment's settings built in. After a production incident, the team finds that the production image contained a newer version of a transitive dependency than the image that passed staging.
The team wants a guarantee that the exact bits running in production are the ones that were tested in staging. What should it change?
Show answer and explanation
Answer:
DORA's deployment automation guidance says to use the same packages in every environment and to keep environment-specific configuration out of those packages. That way, the packages deployed to production are known to be the ones that were tested. The Twelve-Factor build/release/run model says the same thing: a build happens once, and a *release* is that build combined with one deployment's config. Building once and promoting the identical artifact, with settings added at deploy time, gives the guarantee the team wants (B).
Option A does not help. The stages already build from the same source. Same source does not mean same binary, because dependency resolution, base images, and the build environment can all change between builds. That is how this incident happened.
Option C tests a different build in production, but that build still differs from the one that passed staging. Each rebuild keeps the risk of drift and makes the production stage slower.
Option D would catch this particular kind of difference, but only after the pipeline has wasted a rebuild. Other differences between builds would still slip through. Because settings are built into each image, the images are also different by design, so the stage-to-stage guarantee never holds.
References: Deployment automation (dora.dev); The Twelve-Factor App: Build, release, run