When we build software, we want to get it into the hands of users as quickly as possible. If nobody is using what we build, what was the point?
The first deployment is usually the easy one. A pipeline runs, it deploys the application, and everything works.
The challenges come after.
What happens when we need to make a change? What happens when we need to rollback a change in the future?
This is where immutability comes in.
What is Immutability?
Immutability is the idea that something does not change after it has been created.
In the context of deployments this means we build a version of our application once, and that exact version is what gets deployed.
The artifact that leaves the build pipeline should be the same artifact that gets deployed to all of our environments. No rebuilding on the fly, no building changes during deployment.
Just a promotion of the same version through the environments - the only difference might be changing a version number from an RC to stable, but that is implementation semantics.
Why do we need Immutability?
The main benefit of immutability is confidence.
When we use an immutable artifact for a deployment we gain several things:
- A clear history of what has been deployed
- The ability to reliably rollback
- Consistent deployments across environments
- Reduced risk of “it worked in test but not in production”
Rebuilding the application for every deployment, we lose those guarantees.
Even if we build from the same commit, the output may not be 100% identical. Dependencies could have changed, the build environment could have changed, and there are many other factors that could lead to a different output. This means that we can’t guarantee that what we are deploying is the same as what we tested.
Immutable arifacts removes the uncertainty.
How do we achieve Immutability?
The exact implementation depends on teh tooling and platform you’re using, but the principle is the same.
Build once. Store it. Deploy that exact artifact.
One common approach is using containers and a registry. A pipeline builds a container image, tags it with a version, and pushes it to a registry. That image becomes the immutable deployment artifact.
When deploying, the platform simply pulls the required version:
- The latest version for a new release
- A specific version when rolling back The key point is that the image itself never changes.
If containers aren’t part of the stack, the same idea still applies using artifact repositories.
For example:
- Azure DevOps Universal Packages
- NuGet feeds
- npm registries
- Maven repositories
Libraries already follow this pattern naturally. We publish a versioned package and consumers install that version.
Application deployments should work the same way.
What happens if we don’t have Immutability?
Without immutability, deployments often rely on rebuilding from source for each release.
This might not sound like a big deal.
The rollback process becomes:
- Find the last known good commit
- Rebuild the application from that commit
- Deploy the new build and hope it works
But you can’t guarantee that the rebuilt artifact is identical to the original one.
This means rollback becomes guesswork, and rollback should never rely on guesswork.
Conclusion
Immutability is one of the simplest and most effective ways to make deployment safer.
By building an artifact once and storing it as a versioned release, we gain:
- Reliable rollbacks
- Consistent environments
- Clear deployment history
In practice, this leads to something valuable:
boring deployments
And in production systems, boring is exactly what we want.
Immutability is a fundamental principle of software development that we should all be following. It allows us to have a clear history of versions, and it allows us to rollback to a previous version if something isn’t working. It is a risk to not have immutability, and it is a risk that we should never take. We should always be building a version of our application and storing it in a registry, so that we can easily access it when we need to deploy or rollback.
