Identify the long running stages that don’t need to run sequentially. For example you may run static code analysers, a Sonar code quality scan and also a Checkmarx cxSAST security scan. These can be run independently and so are good candidates to run at the same time. They also tend to take a few minutes which is generally longer than most other build tasks.
Azure Pipelines allows stages to be run in parallel by simply not specifying a dependsOn to indicate dependent jobs
jobs: - job: Windows pool: vmImage: 'vs2017-win2016' steps: - script: echo hello from Windows - job: macOS pool: vmImage: 'macOS-10.14' steps: - script: echo hello from macOS - job: Linux pool: vmImage: 'ubuntu-16.04' steps: - script: echo hello from Linux
Quick feature builds, Full Pull Request builds
Rather than run all your build tasks for all branches including feature branches, think about moving longer running tasks to only execute on pull request builds. For example you could move the Sonar code quality scan to only run when merging to master through a pull request. The downside to this is that developers are getting the feedback slightly later in the cycle but one way to mitigate this is to run SonarLint within your IDE to get feedback as you code. https://www.sonarqube.org/sonarlint/
Downloading dependencies can be bandwidth intensive and time consuming. By caching the third party packages that are needed for your build you can avoid the cost of downloading each time. This is especially important if you use disposable agents that are thrown away after executing their build stage.
Azure Pipelines also supports caching across multiple pipeline runs.
Call my Agent
Check how many agents you have available to run pipeline tasks. If you are running tasks in parallel you will need multiple agents per pipeline. Check the queued tasks and consider increasing the number of available agents if you see tasks are waiting for others to complete.