We’ve all seen the culprits that constantly add time to builds. One might observe that your NPM install or Nuget restore can take several minutes. I remember back to the times of CC.Net in 2005 when a small application build could happen in 45 seconds, including unit tests. And 10 minutes as a “thou shall not go over this” threshold. So we cannot allow NPM or any other step to take minutes. We have to ferret that out.
The answer is the same as code performance profiling. Find out where every build is spending the same time doing work that adds no value or doesn’t vary often. Then we cache the result. For so many builds, these are the culprits that take time but typically aren’t the changes that are being tested from build to build:
- Obtaining a build server (when choosing hosted build agents)
- Cloning the source
- Package restores
- Copying/archiving build artifacts
Here are my common solutions for reducing these common culprits (I’d be interested to know how others have eliminated these time sucks)
- Use our own Azure VMs as the build agents (running multiple agents on a single VM) – always available at a moments notice
- Let Azure Pipelines be a little less aggressive with cleaning source and instead have the build script delete the build directories at the beginning – removes need for a full clone and can just be a pull (works most of the time and requires probably a monthly purge for a clean clone, but saves SOOO much time)
- a) retain cloned working tree so that the previous package restore is used for subsequent builds or b) check in packages so that package restores are not necessary for every build
- Once builds are working and reliable, only archive the build artifacts that are directly used by the release pipeline (typically the nuget packages that house the application components)