I’m currently working on a monolithic application using Azure DevOps Release Pipelines (classic UI, not YAML). The application needs to be deployed to 11 production environments, and each environment requires its own unique set of tasks to ensure an update with zero downtime.
The problem I’m facing is that:
-
Complex UI: To accommodate all 11 production environments, the release pipeline now has a huge number of stages. I’m already at 29 stages, and I’m not even halfway through configuring all environments. Managing and visualising the pipeline is becoming incredibly difficult.
-
Re-running Failed Stages: If I try to group multiple environments within a single stage to reduce the number of stages, the problem is that if any job within that stage fails, I am forced to re-run the entire stage. Azure DevOps classic pipelines do not allow re-running individual jobs within a stage, which is frustrating when only one environment fails.
-
No Downtime: Each environment requires specific tasks and jobs to ensure an update without downtime. These tasks vary across environments, so I can’t use a “one-size-fits-all” approach or shared templates.
I want a cleaner way to structure this release pipeline to achieve the following:
- A single release pipeline for all 11 production environments.
- Fewer stages to simplify the UI and improve manageability.
- The ability to re-run only specific environments/jobs if something fails, without re-running an entire stage.
- Retain environment-specific tasks to ensure updates with no downtime.
What I’ve Tried:
- Combining tasks into fewer stages: This reduces the number of stages but makes failures harder to manage because I can’t re-run individual jobs.
- Parallel jobs within a stage: Helps reduce runtime, but doesn’t solve the re-run problem.
- Task Groups: While task groups help with reusability, they don’t address the core complexity of the pipeline structure.
Is there a better way to simplify this classic Azure DevOps release pipeline? I need something that:
- Reduces the number of stages.
- Allows finer control over failed environments/jobs.
- Can still accommodate environment-specific tasks.
There must be a way to do this or are release pipelines not tailored to a monolithic applications need through 1 stage? Am i restricted to just using YAML?
Thanks in advance!
1
This is probably not the answer you are expecting to hear, but how will a gigantic pipeline or stage solve the problems you’re facing? Your first (and probably most important) goal should be reducing complexity, not the number of pipelines, stages and/or jobs.
In the short/medium-term consider:
-
Creating task groups for each set of tasks in order to reuse functionality across pipelines/stages/jobs
-
Creating a pipeline for each environment in order to reduce complexity and be able to manage each environment independently
-
Organizing stages and jobs logically according to functionality and considering which ones can (or should) run together, in case of failure or not
These 3 steps should help you solve most of your problems.
The long-term strategy is to use YAML pipelines and reusable templates to manage your pipeline(s).
1