Build Artifacts Once: Embracing Immutable Containers and Avoiding Rebuild Anti‑Pattern

A conclusion from the previous practice (that the same artifact/package should be deployed in all environments) is a concrete case where an artifact should be built only once.

The whole concept around containers (and previously VM images) is that of immutable artifacts. Applications are built only once, containing the latest features to be released.

Once the artifact is built, it should move unchanged from each pipeline step to the next. Containers are the perfect tool for this immutability, allowing you to create an image only once (at the start of the pipeline) and promote it through successive steps to production.

Unfortunately, a common anti‑pattern observed here is that companies promote source code commits rather than container images. Source code commits are processed at pipeline stages, and each step rebuilds by repeatedly checking out the source.

This is a poor practice for two main reasons. First, it makes the pipeline very slow because packaging and compiling software is a lengthy process, and repeating it at every step wastes time and resources.

Second, it breaks the earlier rule. Recompiling the code commit at each pipeline step opens a window that can produce artifacts different from those previously built. You cannot guarantee that what is deployed to production matches what was tested in the pipeline.

About Us

Zeyang, a DevOps practitioner, focuses on enterprise‑level DevOps operations and development technology sharing, mainly covering new Linux operations techniques and DevOps courses. With rich hands‑on experience, his courses aim for practicality and have earned wide recognition.