A release is a version made available for use. A deployment is the act of putting a build into an environment. A software version is an identified revision of an application. A build is an artifact produced from a commit. An environment is a place where a build runs. A feature flag changes behavior without another deployment and without another release.
Version 2.4.0 is offered. Production still shows the old tax line.
Fictional Lantern Works tags software version 2.4.0, builds it, deploys that build to staging, deploys it to production, and leaves the tax-line flag off. The release notes say 2.4.0 is out. A buyer sees no tax line. Both statements are true, and the status page that says "deployed" has not said which fact it meant.
A version, a build, and a release
2.4.0 in this example is the version number people use for the software version. The scheme, semantic versioning or something else, is not part of the identity of the concept. A version is not a build. Building the same sources again can produce another artifact of the same version.
Build 1842 in the example is one build, the bytes a deployment can put into an environment, and one artifact of version 2.4.0. A second build of the same commit would be a different build. A build of a commit that has not been given a version leaves the version empty. The number 1842 is invented. A team may store one identifier that is used for both the version and the build. The two concepts stay different.
For software, release version names the version a release makes available. The version identifies the software. The release is the decision to offer it. A release of a service, with no software version, leaves the version empty. The same release can be deployed more than once and into more than one environment. It is not a sprint, and it is not an epic. Epic vs user story vs task keeps the backlog on the other side of this line. Work items included in the release are a list on the release. A deployment of the release is a further fact.
An environment is a place, not an event
An environment is a subset of infrastructure used for a particular purpose. The usual kinds are development, test, staging, and production. Development is where the software is changed. Test is where it is checked. Staging is a production-like place used to rehearse a release. Production is where the service's users are. Organizations use other names and other counts, so those four kinds are not a closed list. A sandbox is still an environment type. The type is the organization's own word for the kind of place.
An environment is not a deployment into it and not a release. Software that runs in development is not, by that fact, running in production. The word can also mean external conditions. This concept is the infrastructure used for a purpose.
A deployment puts bytes in one place
Deploying 2.4.0 to staging and deploying it to production are two deployments, even though they carry the same release. A deployment can fail to reach the environment while the release still exists. A deployment is not a version and not the environment it targets.
The deployment outcome records what this deployment did: whether it reached the target environment, and whether the service then had to be remediated, for example by a rollback or a follow-up fix. A deployment that never reaches production is not counted in deployment frequency and is not a change failure. A deployment that reaches production and degrades the service is counted in the frequency and in the change failure rate. The outcome of one deployment is not either of those rates. DevOps Research and Assessment (DORA) metrics and mean time to restore (MTTR) is how a window of outcomes becomes those two measures.
It is also not a change request. The change request is the proposal. A deployment is one way that proposal is carried out, when one is recorded as the deployment change request. A deployment can have no change request, and a change can be carried out by something other than a deployment. Incident vs problem vs change is the proposal. This article is the act.
Putting bytes into an environment is not the same as showing new behavior to users.
A feature flag changes behavior without a new deployment
The feature flag is usually shipped in a deployment while it is off. Turning it on is a separate act and is not itself a deployment. The same deployed build can behave differently for different users, or in different environments. In the example the tax line stays off in production and on in staging. The flag is not a version, not a build, and not an environment. Lead time for a change ends at the production deployment, not when this flag later exposes the change.
| Fact | Invented Lantern example | What it is not |
|---|---|---|
| Software version | 2.4.0 | Not the build, not the deploy |
| Build | 1842, from one commit | Not the version, even if a team stores one identifier for both |
| Release | 2.4.0 made available for use | A service release can leave the version empty |
| Environment | Staging, then production | Not a closed list of four names |
| Deployment | One to staging, one to production | Not the release, and able to miss the environment |
| Deployment outcome | Each act: did it arrive, and did a fix follow? | Not deployment frequency, and not the change failure rate |
| Feature flag | Tax line off in production | Not a deployment |
A release deployed twice is two deployments. A flag flip with no deployment is not a deployment record. Deployment frequency can still count that flip once when the team treats the release to users as the production release, and it does not count the flip again when the flip is the same event as a deployment. The version, the build number, and the flag state in this story are made up.
