skip to content

In Octopus Deploy, what is the difference between a release and a deployment, and what does it mean to promote a release?

level: juniorimportance: must knowfreq 78%

answer

  1. one noun is a thing, one is an act
  2. created once, deployed many times
  3. snapshot taken at creation time
  4. promotion adds no new version number
  5. Octopus never builds the package

basics

~20 s

In Octopus Deploy a release is an immutable, versioned snapshot of a project's deployment process, variables and chosen package versions. A deployment executes that release into one environment; promoting means deploying the same release to the next environment.

solid answer

~50 s

Octopus splits the noun from the verb. A **release** is a first-class object you create once in a project: it captures a version number, the deployment process as it looked at that moment, the project's variables, and the exact package versions selected from the feeds. A **deployment** is one execution of that release against one environment — Dev, Test, Production. **Promotion** is just deploying the same release again into the next environment, with no rebuild and no new version. That is the whole point of the product: the artifact your CI server built and pushed is the artifact that reaches Production, and the audit trail shows one version walking through environments. Octopus itself does not compile anything — your build server pushes packages, then creates the release. Because the release is a snapshot, editing the project's steps afterwards affects only releases created from then on.

go deeper

for a junior

Be ready to say plainly that a release is a versioned snapshot created once, and a deployment is one run of that release into a single environment. Mention that promoting means deploying the same release to the next environment.

for a middle

Explain what the snapshot contains — the deployment process, the variables and the selected package versions — and why that makes a release immutable and a rollback a simple redeploy of an earlier release.

for a senior

Show why this split matters in practice: the artifact tested in a lower environment is the one that ships, environment differences come from scoped variables rather than rebuilds, and the audit trail records who deployed which version where.

for a principal

Own the tradeoff of buying a dedicated release-management product at all: you gain an auditable promotion model and approvals separated from build, at the cost of a second system, its own permissions model, and a boundary your CI pipelines must hand off across.

## Why the split exists Most CI tools have one concept: a pipeline run. Build, test and deploy all happen inside it, and "deploy to Production" is a later stage of the same run. Octopus Deploy exists because that model gets awkward the moment shipping is governed by people and process rather than by a green build. It separates *making a versioned thing* from *deciding where that thing goes and who approves it*. The two nouns that carry the split are **release** and **deployment**. ## What a release actually is A release belongs to a **project** and carries a version number (for example `1.4.7`). When Octopus creates it, it takes a **snapshot** of three things: - **The deployment process** — the ordered steps the project runs (deploy a package, run a script, ask for manual intervention, and so on), exactly as they were configured at that instant. - **The variables** — the project's variables plus any library variable sets it includes, with all their scopes. - **The selected package versions** — for each step that deploys a package, the specific version chosen from a feed. That snapshot is what makes a release immutable and reproducible. If someone reorders the steps tomorrow, releases already created keep the process they were born with; only new releases pick up the change. Creating a release deploys nothing by itself — it is a declaration that "this exact combination is a candidate for shipping". Octopus does not build the software. Your CI system (GitHub Actions, TeamCity, Azure Pipelines, Jenkins — whatever the shop uses) compiles, tests, packages, and pushes the package into a feed such as the Octopus built-in feed or a registry. It then asks Octopus to create a release. From that point the build system is out of the picture. ## What a deployment is A deployment is one execution of a release against one **environment**. Environments are named groups of deployment targets — the machines, clusters or cloud services that make up Dev, Test, Staging or Production. The same release deployed to Test and to Production runs the *same* snapshotted steps; what differs is which targets are involved and which variable values win, because variables can be scoped per environment. A connection string, a hostname or a feature toggle resolves differently in Production without changing the release. Deployments are the unit that succeeds or fails, that appears in the audit log, and that a person is recorded as having triggered or approved. ## Promotion "Promoting" a release is nothing more exotic than running another deployment of the *same* release into the next environment. No rebuild, no repackage, no new version number. This is the product-level expression of build-once-deploy-many: the binary that passed testing in Test is byte-for-byte the binary that lands in Production, so a passing test in a lower environment is real evidence about the higher one. Which environment you may promote to next is not arbitrary. A **lifecycle** attached to the project defines the ordered phases of environments and what must succeed before the next phase opens, so a release cannot jump straight from Dev to Production unless the lifecycle says it can. ## Where candidates get it wrong The common confusion is treating "release" as a synonym for "deployment" — saying "we did three releases to Production last week" when what happened is three deployments of possibly one release. The second confusion is assuming a promotion re-runs CI. It does not; if you find yourself rebuilding an artifact per environment, you have thrown away the property that makes promotion meaningful, and a rollback becomes "rebuild an old commit and hope" instead of "redeploy release 1.4.6". The third is expecting edits to the project to reach releases that already exist. They do not — that is the snapshot doing its job. The practical consequence is that a rollback in Octopus is usually just deploying an earlier release again, because that earlier release still knows its own steps, its own variables and its own package versions. ## The interview framing When an interviewer asks this, they are checking whether you understand that in a regulated or approval-heavy shop, shipping is a decision about an existing versioned object, not a rerun of a build. If you can say "the release is created once and promoted unchanged; the deployment is the act of putting it into an environment", you have the model.

  • When you promote a release from Test to Production, does anything get rebuilt?
    No. Octopus does not compile or package anything — your CI system pushed the package to a feed before the release was created, and the release pinned that exact package version. Promotion re-executes the same snapshotted process against Production targets. Nothing is rebuilt, so the artifact that passed Test is the artifact that ships.
  • Where does a release's version number come from?
    From the project's release versioning setting. Octopus can generate it from a template, or take it from the version of a package deployed by a nominated step so the release number tracks the build. Whoever creates the release — a build-server plugin, the CLI, or a person in the UI — can also supply it explicitly. It must be unique within the project.
  • How does rollback work if a release is immutable?
    You deploy an earlier release again. Because that release still carries its own snapshotted process, variables and package versions, redeploying it reconstructs the previous state without rebuilding anything from source. That is why immutability matters: rollback is a redeploy of a known-good object, not an attempt to reproduce an old build.

saying these in an interview costs you the question

  • Uses release and deployment as interchangeable words
  • Thinks Octopus compiles or builds the application
  • Believes each environment gets its own rebuilt artifact
  • Assumes editing project steps changes existing releases
  • Says promotion creates a new version number

context

resolving links…