We replaced five Azure DevOps definitions – a change‑decider, two build pipelines and two release pipelines – with a single decider, one generic build, and one release that contains a stage per module. The new design passes the target module and service as queue‑time parameters, tags the build run, and lets Azure DevOps’s tag filters decide which release stage runs. This consolidation eliminates duplicated build and release logic while keeping the same functional outcome.
What Changed
The original setup duplicated the same image‑building and chart‑publishing steps across two separate build definitions, and repeated identical deployment tasks in two release definitions, each tied to a specific module via variable groups. The decider now holds the only CI trigger, inspects changed paths, and queues the generic build with service and module parameters. The generic build produces the artifact, tags the run (e.g., module-b), and the release uses Azure DevOps tag filters to run the matching deployment stage.
Why It Matters to Practitioners
Removing duplicated pipelines cuts maintenance overhead: a change to the shared image build or deployment steps needs to be made in only one place. Adding a new module no longer requires a new build‑release pair; you only add a map entry, a variable group, and a stage. This reduces the risk of configuration drift, speeds onboarding, and simplifies audit trails because each pipeline retains a stable ID even after renaming.
Implementation Highlights
The decider constructs a REST call to the Azure DevOps Build API. The parameters field must be a JSON‑encoded string, which requires double‑escaping of inner quotes. A minimal example looks like:
BODY="{\"definition\":{\"id\":$BUILD_ID}, \"sourceBranch\":\"$(Build.SourceBranch)\", \"sourceVersion\":\"$(Build.SourceVersion)\", \"parameters\":\"{\\\"service\\\":\\\"$SERVICE\\\",\\\"module\\\":\\\"$MODULE\\\"}\"}"
Queue‑time variables must retain the allowOverride: true flag; cloning a definition can drop this flag, causing the decider to fail when passing values. The generic build does not have its own CI trigger; it only runs when the decider queues it. After the build finishes, it publishes the artifact and adds a run tag derived from the module parameter. Azure DevOps rejects a colon in the tag path, so a hyphenated form (e.g., module-b) is used.
Operational and Security Considerations
Because the decider pins each child run to the exact commit it inspected, later pushes cannot alter the artifact that a given release consumes. This behavior relies on comparing the current commit to its first parent on protected branches that receive changes via merges. For repositories that allow multi‑commit pushes, the decider must compare the before and after commit IDs supplied by the build event.
Tag‑based stage selection means that a non‑matching stage reports “Artifact conditions not met” rather than a failure, which is an expected outcome. However, the same status can also indicate a malformed condition, so operators should verify the stored condition (full refs/heads/… value) rather than relying on the UI’s shortened branch name.
Renaming pipelines preserves their internal IDs, so historical runs remain linked. Nevertheless, UI elements such as build validation policy labels and snapshot metadata may retain the old names, requiring manual updates to avoid confusion. Deleting a build that still has releases referencing it triggers an HTTP 409 error; the safe path is to disable its trigger, remove references, and archive the definition.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
Adopt a single, parameter‑driven build and a tag‑filtered release to eliminate duplicate pipeline definitions. Verify that queue‑time variables keep the override flag and that your decider correctly captures commit IDs for the branch strategy you use. Update any UI‑level references after renaming pipelines to keep documentation accurate. By consolidating pipelines, you reduce change‑management overhead, lower the chance of divergent configurations, and make it easier to scale the delivery chain as new modules are added.