1.1.2.5 Pipeline Delivery Support

Pipeline delivery support refers to the set of capabilities Docker provides that make it suitable as the packaging and execution mechanism inside continuous integration and continuous delivery (CI/CD) pipelines, allowing a pipeline to build, validate, and ship an application as a single consistent artifact.

Containers as Pipeline Build Agents

Many CI systems run each pipeline step inside its own container, which guarantees that the tools available to a build step are exactly the ones declared, rather than whatever happens to be installed on a shared build server.

job:
  image: node:20
  script:
    - npm install
    - npm test

This isolates pipeline runs from each other: two pipelines using different language versions can run on the same underlying infrastructure without conflicting.

Building the Deployable Artifact Inside the Pipeline

A typical pipeline stage builds the application image directly, tags it with a commit identifier, and pushes it to a registry, so the artifact produced by CI is the same artifact that gets deployed.

docker build -t registry.example.com/myapp:$CI_COMMIT_SHA .
docker push registry.example.com/myapp:$CI_COMMIT_SHA

Running Tests Inside the Built Image

Rather than testing against a separately assembled environment, the pipeline can run automated tests inside a container started from the exact image that would be deployed, closing the gap between "tested" and "shipped."

docker run --rm registry.example.com/myapp:$CI_COMMIT_SHA pytest -q

If the tests fail, the pipeline stops before the image reaches a deploy stage, preventing an untested artifact from progressing further.

Layer Caching for Faster Pipelines

Docker's layer caching can be reused between pipeline runs, so steps like dependency installation only re-execute when the underlying files actually change, which keeps pipeline duration manageable even as the codebase grows.

docker build --cache-from registry.example.com/myapp:cache -t myapp:latest .

Supporting Deployment Stages

Once an image has passed its pipeline checks, later stages can deploy it by referencing its tag, whether that means restarting a single container, updating a Docker Swarm service, or triggering a Kubernetes rollout — all of them consuming the same pipeline-produced image.

docker service update --image registry.example.com/myapp:$CI_COMMIT_SHA myapp

Why This Matters for Delivery Speed

Because the build, test, and deploy stages all operate on the same container image rather than on separately maintained artifacts, pipeline delivery support reduces the number of places a discrepancy between "what was tested" and "what is running" could be introduced.