Course contentsShow
← C#
Lesson 1842 of 1,90817. Deployment and Cloud ArchitectureFree lesson

Image Tagging Strategies for Immutable Releases

Design a versioning scheme for container images that integrates with production release cycles.

In this lesson, you will learn how to design a robust, immutable tagging strategy that ensures your .NET container deployments are deterministic and traceable.

The Problem with :latest

In production environments, using the latest tag is an anti-pattern. Because the latest tag is mutable—meaning it points to a different image manifest over time—you lose the ability to roll back to a known state or guarantee that the code running in Staging is byte-for-byte identical to the code deployed in Production. For immutable releases, every deployment must be uniquely identified.

The Semantic Versioning + Commit Hash Strategy

A robust tagging strategy combines Semantic Versioning (SemVer) with the specific Git commit hash. This provides both human-readable context and machine-verifiable auditability.

When your CI/CD pipeline builds your .NET application, it should apply at least two tags to the image:

  1. The Version Tag: myapp:1.2.4 (Used for environments or stable releases).
  2. The Immutable SHA Tag: myapp:1.2.4-a1b2c3d (Used for specific deployments).

By coupling the Git hash, you ensure that even if a version is re-built, the resulting image is uniquely tethered to the source code state.

Implementation Pattern

In your pipeline, you can capture the Git hash and pass it to your Docker build command:

# Capture the short SHA
COMMIT_SHA=$(git rev-parse --short HEAD)
VERSION="1.2.4"

# Tag with both Version and SHA
docker build -t myregistry.com/app:$VERSION-$COMMIT_SHA -t myregistry.com/app:$VERSION .
docker push myregistry.com/app:$VERSION-$COMMIT_SHA

Why this achieves Immutability

When your Kubernetes manifest or orchestrator references the specific SHA tag, you eliminate "floating" references. If a bug is discovered, you know exactly which artifact caused the issue, and your rollback strategy becomes trivial: simply update the deployment manifest to point back to the previous known-good SHA tag. This prevents the "it worked on my machine" syndrome and ensures that your production environment remains a static, reproducible artifact.

Key Takeaway: Never rely on mutable tags in production; always use a combination of semantic versioning and commit-specific hashes to ensure every deployment is uniquely identifiable and immutable.