You changed a project variable in Octopus Deploy, then redeployed an existing release to Production, but the old value was still used. Why, and what are your options?

## What actually happened Octopus Deploy's release is an immutable snapshot, and the snapshot includes variables. At the moment the release was created, Octopus recorded the project's variables, every library variable set the project includes, and all of their scopes, and stored that copy on the release. Deploying — or redeploying — replays that stored copy. The project's variable editor shows *current* values, which is why the UI looks like the change took effect while the deployment plainly did not use it. This catches people because most CI systems read configuration live at run time. Octopus deliberately does not, for the same reason it pins package versions: a release that passed Test must be re-deployable to Production and produce the same result. If variables were read live, a value edited between the Test deployment and the Production deployment would silently change what shipped, and the audit trail would not show it. ## Confirming the diagnosis Before reaching for a fix, verify it rather than assuming. Every deployment records the variables that were in effect for that run, and the task log shows the value each variable resolved to (sensitive values are masked). If that snapshot shows the old value while the project editor shows the new one, the diagnosis is confirmed. This also rules out the two neighbouring causes: a **scoping** mistake, where the new value exists but is scoped to an environment or role that does not match this deployment, and a **substitution** mistake, where the variable resolved correctly but the file transform that was supposed to write it into configuration never ran on that step. ## The two fixes **Update Variables on the release.** This action re-snapshots the release's variables from the project's current values and its library variable sets. It does *not* re-snapshot the deployment process — the steps stay exactly as they were — and it does not change the package versions. This is the right move when a release is already partway through its lifecycle and you need to correct a value without disturbing what has been tested. **Create a new release.** Everything is re-snapshotted: variables, process, package selection. This is the right move when the variable change is genuinely part of shipping something new, and it is the honest choice most of the time, because it gives you a fresh version number to talk about and an audit record of what changed. There is a real judgment between them. Updating variables on a release breaks the property you were relying on: the release that passed Test is no longer bit-identical in behaviour to the one going to Production. Do it knowingly, and re-deploy to a lower environment afterwards if the value has any behavioural weight. ## What is *not* snapshotted Not everything is frozen. Values a step fetches at deploy time — a secret read from an external secret store by a script or a dedicated step, or a value computed by an earlier step and set as an output variable — are resolved during the deployment, not captured at release creation. Some teams lean on this deliberately: keep genuinely rotating material (credentials, tokens) outside the snapshot so that rotating it does not require touching releases, and keep declarative configuration (hostnames, feature toggles, sizes) inside the snapshot where it is versioned and auditable. That is a good line to be able to draw in an interview. Variable substitution itself happens at deploy time against the snapshot. A configuration file containing a placeholder is transformed as the step runs: ```json { "ConnectionStrings": { "Default": "#{Database.ConnectionString}" } } ``` The `#{...}` syntax is resolved from the release's variable snapshot, with scoping applied for the environment being deployed to — which is exactly how one release produces different configuration in Test and Production without any rebuild. ## Scoping, the adjacent trap Variables are scoped — to environments, target roles, specific machines, steps, channels or tenant tags. When several values of the same name match the current deployment, Octopus picks the most specifically scoped one. If two matches are *equally* specific, the outcome is ambiguous: Octopus will pick one, and you should not rely on which. Treat equally-scoped duplicates as a configuration defect to be removed rather than a precedence rule to be learned. ## The interview point What is being tested is whether you understand that Octopus trades live configuration for reproducibility on purpose. A candidate who says "variables must be read at deploy time, so something is caching" has the model backwards. A strong answer names the snapshot, names Update Variables as the surgical fix, prefers a new release as the default, and flags that re-snapshotting a mid-flight release weakens the guarantee that promotion is supposed to give you.