Why Old Azure DevOps Releases Survive a Pipeline Cutover

Old Azure DevOps releases continue to function after a pipeline cutover despite using outdated information. The current Azure DevOps release definitions employ new names and identities, while older releases still contain the retired Helm release name and image path. Approximately 45 of these older releases across five definitions retain the old deployment task and are still executable.

The Classic release retains the task graph, which means that editing the definition does not rewrite the stored task graph in existing releases. The cutover modified four related values, including the image repository path, packaged chart name, Helm release name, and Kubernetes resource names. The current definition shows only the replacement values, while existing releases still store the older combination.

The old task uses Helm with the –install flag, which will attempt a second installation if it cannot find that name, leading to an attempt at upgrading the current release instead of installing under the retired identity. The forward rename caused the old release to refuse the new release’s duplicate ingress because Helm had already created the Secret, ServiceAccount, Service, and Deployment.

The stale redeploy left those objects remaining. Existing releases still store the old combination, making it necessary to edit the definition and create new releases to use the new values. Stale releases can still be found, and their Redeploy action is gone. After abandoning stale releases, they remain visible but cannot be moved back to Active.

To complete the migration, checks should be made on active releases created before the migration boundary and inspect each release payload for stored scripts, Helm release names, image paths, and captured variable values.