devopsy.kinsta.cloud

Author: Ahmed Tariq

Why Old Azure DevOps Releases Survive a Pipeline Cutover
I had finished renaming a set of back-end deployments in a nonproduction environment. The current Azure DevOps release definitions used the new names, the Kubernetes workloads ran under the new identities and every current deployment pointed at the replacement image repositories.

Then I opened an older Azure DevOps Classic release. It still offered Redeploy.

That release retained the inline deployment task captured when someone created it, including the retired Helm release name and image path. About 45 more releases across five definitions held the same task. Nobody redeployed one, but each remained an executable record of the old delivery path.

Figure 1: Editing a Classic Release Definition Leaves Already-Existing Releases Untouched

A Classic Release Stores its Task Graph

Microsoft describes a Classic release as a snapshot of the information required to run its stages and tasks. Azure DevOps can deploy the same release to a stage more than once. Editing the definition changes later releases but does not rewrite the task graph stored in releases that already exist.

The cutover changed four coupled values: The image repository path, the packaged chart name, the Helm release name and the Kubernetes resource names. The current definition showed only the replacement values. Existing releases still stored the old combination, which is why checking the definition alone would have missed the executable path.

The old task called Helm with –install. Its release name no longer existed. Helm documents the flag as an instruction to install when it cannot find that name. A redeploy would therefore attempt a second installation under the retired identity rather than upgrade the current release.

The Forward Rename Exposed the Failure Order

I did not run a stale release. The forward rename had already shown how this chart behaved when two releases wanted the same route.

While the old release still held the host and path, the admission webhook refused the new release’s duplicate ingress. The refusal happened after Helm had created the Secret, ServiceAccount, Service and Deployment. The task used neither –atomic nor –cleanup-on-fail, so those objects remained.

A stale redeploy could have attempted the same installation under the old name. Figure 2 describes that conditional path. The observed event was the late ingress refusal during the forward rename.

The old release also replayed the variable values captured at release creation. I later verified that changing a linked variable group did not change an existing Classic release. A newly created release was required to use the new values. Therefore, I treated database access as unproven unless the captured credentials and network path were checked separately.

The refused ingress did not make the remaining objects invisible or prove that they were isolated. Cluster operators could still see the Secret, ServiceAccount, Service and Deployment, and the Service could remain reachable from inside the cluster. Whether a pod could do useful work still depended on the image and its captured values.

Figure 2: The Conditional Stale-Redeploy Path, Based on the Failure Order Observed During the Forward Rename

The Executable Path Removed in Two Stages

My first containment step was to delete the retired image repositories after confirming that no active workload or current pipeline referenced them. A stale deployment could then create objects, but its pod could not pull the old image and would remain in ImagePullBackOff. This reduced the issue to orphan objects and a confusing failed release.

Deleting those repositories also removed image-level rollback through the retired path, so I checked the current releases and workloads first.

I used the Release API to filter each definition by active status and maximum creation time. The cutover timestamp identified candidates, but each stored task determined whether a release was stale. The five definitions contained a total of 46 stale releases — 25, 8, 8, 4 and 1.

Azure DevOps supports changing an active release to abandoned. I tested one target first, then tried to restore it. The API returned VS402966, stating that a release could not move from Abandoned back to Active. The release remained visible for audit history, but its Redeploy action disappeared.

That test made the next 45 changes a deliberate permanent decision. After abandoning them, I queried the definitions again, compared the Helm release set and checked the live endpoints. Every remaining active release postdated the cutover, and the running workloads had not changed.

Figure 3: The Cleanup Order, Including the One-Release Test That Exposed the One-Way Transition

Checks to Add to a Classic Release Migration
- Query active releases created before the migration boundary and follow continuation tokens.
- Inspect each release payload instead of relying on the current definition.
- Check stored scripts, Helm release names, image paths and captured variable values.
- Check –install, –atomic and –cleanup-on-fail before predicting Helm’s failure path.
- Verify retired images and captured credentials separately.
- Test abandonment on one genuine target and treat it as one-way unless your platform proves otherwise.
A green deployment proves that the new path works. For a Classic pipeline with inline deployment logic, I now consider the migration complete only when historical releases can no longer execute the retired path.
September 25, 2026
How I Consolidated Duplicate Delivery Pipelines With Parameters and Build Tags
Two modules in a repository had near-identical Azure DevOps build and release definitions. A third would have required another pair.

The delivery chain used five definitions: one change decider, two builds, and two releases. I consolidated it into one decider, one generic build, and one release with a deployment stage for each onboarded module. The count excludes package and pull request validation.

Figure 1. The consolidation removed one duplicated build and one duplicated release.

The Decider Passes the Module as a Run Parameter

The old builds repeated the same image and chart tasks with different module values. The releases repeated the same deployment tasks with different variable groups. A shared build change required matching edits in both build definitions, and a shared deployment change required matching edits in both release definitions. Adding another module would have required another build and release pair.

I named the shared definitions by product, service, scope, and kind:
```
<Product>.<Service>.<Scope>.<Kind>
```
The decider holds the only continuous integration trigger. It checks changed paths, then queues the generic build with the module and service as parameters. It also fans out shared build-input changes to every registered pair. An optional module value limits manual diagnostic runs.

The decider pins each child to the branch and commit it inspected. A later push cannot change what that child builds. It compares the current commit with its first parent because the protected branch receives changes through merges. Repositories that accept multi-commit direct pushes need to compare the before and after commit IDs from the build event.

The Azure DevOps Build REST API expects parameters as a JSON-encoded string. This reduced example shows the two routing fields and the escaping that preserves their inner quotes:
```
BODY="{\"definition\":{\"id\":$BUILD_ID},\
\"sourceBranch\":\"$(Build.SourceBranch)\",\
\"sourceVersion\":\"$(Build.SourceVersion)\",\
\"parameters\":\"{\\\"service\\\":\\\"$SERVICE\\\",\\\"module\\\":\\\"$MODULE\\\"}\"}"
```
The variables that receive those queue-time values must also retain Azure DevOps’s Settable at queue time option, stored as allowOverride: true. A cloned definition can lose that flag. The decider may identify the correct change, then fail when it hands the values to the child build.

Both registered modules resolve to the same generic build.

The Generic Build Adds the Routing Tag

The generic build has no continuous integration trigger. It receives the service and module, derives the image and chart names, publishes the artifact, and tags the run with a value such as module-b.

I first tried module:module-b, but Azure DevOps rejected the colon in the request path. The hyphenated form worked.

I kept the decider separate from the build because a combined design had triggered releases from dispatcher runs that contained no artifact. After the split, every successful generic build produced an artifact for the release.

Stage Conditions Select the Module After Release Creation

Azure DevOps supports tag filters on both the continuous deployment trigger and individual release stages. Each filter controls a different decision.

The definition trigger decides whether Azure DevOps creates a release. A module-a filter there prevents a module-b build from creating any release. The build stays green and the chain stops without a release record.

The stage artifact condition decides which deployment stage runs after Azure DevOps creates the release:
```
Release trigger
    tag filter: none

Module A stage
    artifact condition: module-a

Module B stage
    artifact condition: module-b
```
Every qualifying completion of the generic build on the configured branch creates one release. The tag selects the matching module stage. For the nonmatching stage, Artifact conditions not met is an expected skip rather than a deployment failure.

The same status can also describe a malformed condition, so the run summary alone cannot prove correct routing. The branch half adds another ambiguity: the interface displays a short branch name, while the stored condition uses a full refs/heads/... value. I checked the stored condition directly.

Figure 2. The parameter selects what the build produces. The tag selects which stage deploys it.

I Used the Other Workload as a Control

I tested the consolidated chain with a change for Module B in a nonproduction environment. The decider queued the generic build with Module B, the build added module-b, and Azure DevOps created one release.

The Module B stage completed successfully. The Module A stage reported Artifact conditions not met. I then checked Module A in AKS and confirmed that it still used its previous container image.

Renames Preserved Execution and Left Stale Labels

I renamed the definitions using the service naming scheme. Azure DevOps kept their IDs, so execution references remained valid. Seven build validation policies still displayed the old pipeline name, and I updated those labels separately.

A snapshot of the release definition taken one week later still held the former build name in its artifact metadata. The release continued to bind by ID, but its interface displayed stale text.

The duplicate definitions also carried deployment history. Azure DevOps returned HTTP 409 when I tried to delete a build because a release still retained runs from it. I disabled its trigger, removed the remaining references, and archived it.

Another Module Adds Three Configuration Items

Another module now needs one decider map entry, one variable group, and one release stage. The generic build derives its tag from the queue parameter, so the team adds no module-specific build or release definition.

The application and environment still require their own preparation, including code and Dockerfile support, a database, a broker vhost, variable values, and Kubernetes namespace resources.

Figure 3. A new module extends the chain without adding a build or release definition.

This pattern fits modules that share a repository, artifact type, build process, and deployment mechanics. A different artifact or approval process may need its own chain. Here, parameters carried the module values, and build tags selected the correct deployment stage.

References
September 16, 2026