While helping a team getting their failing build back up and running I noticed that they were using one big build pipeline that only consists of one stage. This not only made the pipeline more difficult to understand but also makes the build time very long and forces you to rerun the full build if one specific step fails.
Let me walk you through several scenario’s how we logically split this pipeline into multiple stages but before I do that, here is the original YAML pipeline:
In the example above we have a single stage containing all the steps. Time to refactor…
Approach 1 - Build → Test → Publish Stages
Description
This is the most straightforward approach:
Build Stage:
- NuGet tool installation
- Package restore
- Build all solutions
- Angular npm install and build
Test Stage:
- Run unit tests (.NET)
- Run Angular tests
Publish Stage:
- Publish all applications
- Publish build artifacts
Advantages
- Clear separation of concerns: Each stage has a distinct purpose
- Early failure detection: Build failures stop the pipeline before testing
- Easy to understand: Follows natural CI/CD flow
- Good for debugging: Clear failure points
- Scalable: Easy to add deployment stages later
Disadvantages
- Sequential execution: No parallelization between major phases
- Longer total time: Each stage waits for the previous to complete
- Resource inefficiency: Agents may sit idle between stages
Example
Approach 2 - Technology-Based separation
Description
In this scenario we split the pipeline by technology stack:
Backend Stage:
- NuGet operations
- .NET restore and build
- .NET unit tests
- .NET application publishing
Frontend Stage:
- Angular npm install
- Angular testing
- Angular build
Packaging Stage:
- Publish build artifacts
Advantages
- Team specialization: Backend and frontend teams can own their stages
- Technology-specific optimizations: Different pools, tools, or configurations per tech stack
- Parallel execution: Backend and frontend can run simultaneously
- Clear ownership: Easier to assign responsibility for failures
Disadvantages
- Potential duplication: May need to repeat setup steps
- Complex dependencies: Frontend might depend on backend APIs
- Resource overhead: Multiple agents running simultaneously
- Integration testing gaps: Harder to test full-stack integration
Example
Approach 3 - Application-Specific stages
Description
In this scenario we create a stage for each major application component:
Foundation Stage:
- General setup (NuGet, restore, build all solutions)
- Run unit tests
BOSS.Intern.Web Stage:
- Publish BOSS.Intern.Web
SMIL2.Extern.API Stage:
- Publish SMIL2.Extern.API
SNapp2 Stage:
- Angular operations
- Publish SNapp2.Extern.Web
- Publish SNapp2.WorkerService
SmilGo Stage:
- Publish SmilGo.Extern.Web
Artifacts Stage:
- Publish all build artifacts
Advantages
- Independent deployment: Each application can be deployed separately
- Granular control: Fine-tuned control over each application's pipeline
- Selective builds: Can trigger builds for specific applications only
- Microservice-friendly: Aligns well with microservice architecture
Disadvantages
- Many stages: Can become unwieldy with many applications
- Shared dependency complexity: Managing shared libraries and dependencies
- Longer pipeline: More stages mean more overhead
- Maintenance overhead: More stages to maintain and configure
Example
Approach 4 – Parallel execution
Description
With this scenario, we focus on optimizing for speed with parallel stages:
Foundation Stage:
- NuGet, restore, build solutions
Parallel Testing Stage:
- Job 1: .NET unit tests
- Job 2: Angular tests
Parallel Publishing Stage:
- Job 1: Web applications (BOSS.Intern.Web, SNapp2.Extern.Web, SmilGo.Extern.Web)
- Job 2: APIs and Services (SMIL2.Extern.API, SNapp2.WorkerService)
Artifacts Stage:
- Collect and publish all artifacts
Advantages
- Fastest execution: Maximum parallelization reduces total pipeline time
- Resource efficiency: Better utilization of available agents
- Independent failures: One component failure doesn't block others
- Scalable: Easy to add more parallel jobs
Disadvantages
- Complex orchestration: More complex dependency management
- Resource contention: May require more agents simultaneously
- Debugging complexity: Multiple parallel failures can be harder to diagnose
- Agent pool limitations: May exceed available agent capacity
Example
Conclusion
There are probably some other approaches that could work as well. But I would suggest starting with Option 1 (Build → Test → Publish) because it:
- Follows the natural CI/CD flow
- Provides clear failure points
- Is easy to understand and maintain
- Allows for easy addition of deployment stages later
Each stage can have dependencies on the previous one, and you can add conditions to skip stages based on branch or other criteria. You can also run some stages in parallel where there are no dependencies between them.
More information
Stages in Azure Pipelines - Azure Pipelines | Microsoft Learn