Most of the time in a Pipeline is spent in four places:

Some of this is down to how your Pipeline, org and repository are set up, and that's what this article covers. Validations and deployments are also processed by Salesforce, so busy periods on the Salesforce side can add time too. For a step-by-step breakdown of a promotion, see Promoting a change through your Pipeline.

Before changing anything, check where your Pipeline is actually spending its time:

Apex tests are usually the biggest contributor to slow validations and deployments. If an environment is set to run all local tests, every validation and deployment to it runs every test in the org. In larger orgs, that can take hours. As each PR runs its own validation, a few PRs waiting to promote can quickly add up to a queue of many hours.

To check whether tests are your bottleneck, look at the Salesforce test time on the View job performance page.

It's worth reviewing the test settings on each environment's CI job with your team. See Setting Apex test levels for what each option does. Many teams find that dynamic testing, which only runs the tests relevant to your changes, gives a good balance of speed and assurance in earlier environments, while still running all local tests for production. Another option is to use dynamic testing on PRs alongside a nightly job that runs every test in the sandbox, with someone reviewing the results of both.

Bear in mind that Salesforce has code coverage requirements for production deployments, so any change should be agreed with whoever is responsible for your tests. Code coverage in pipelines explains how to see coverage for each feature.

Slow tests also make a difference. If a handful of test classes take most of the time, improving them speeds up every validation and deployment. See Testing best practices for tips.

Quick deploy lets a deployment skip running your Apex tests again, as they already passed during validation. It only saves time when your tests are slow, but in those cases it can save hours.

Quick deploy can only be used when nothing has changed since the validation, so promote soon after validation passes. You can check whether quick deploy was used on the View job performance page, under the Deployments tab. For the full detail, see Quick deploy in Pipelines.

Changes made directly in an org, or deployed using other tools such as change sets, cause your orgs to drift away from what's in Git. This means:

Each promotion runs its own validation and deployment. Promoting related PRs together, for example as a bundle or a release (expanded branching model only), means they share one validation and one deployment, rather than repeating the same work for each.

Every environment in your Pipeline adds a validation and a deployment to each promotion, so it's worth checking that each one earns its place. See Pipeline setup - choosing your environments.

Gearset validates each PR against its target environment. For earlier environments with a high release velocity, for example several releases a day, these validations can create a queue. Some teams turn off PR validations for these environments and rely on the deployment instead.

The trade-off is that errors are found at deployment rather than before it, and a failed deployment to a shared environment can hold up everyone else promoting to it. We'd recommend keeping validations on for production.

A lot of Pipeline time is spent waiting for someone to promote a change. Continuous delivery rules can promote changes automatically once they meet the conditions you set, which cuts out that idle time. They don't make validations or deployments themselves any faster. This may not be available depending on your licensing tier.

A large number of long-running PRs means more conflicts and more semantic merges, both of which add time to promotions. See What does the high merge complexity warning mean? for more on how this builds up.

Your CI job's metadata filter decides which metadata types are compared. For comparisons and validations, including types your team never deploys adds time to every run.

Delta CI jobs work differently. They only retrieve the changed items from the org, so the filter has much less effect on speed, and the size of your repository matters more. See Your Git repository and hosting.

Make sure your filter covers the metadata types your team deploys. Before removing anything, check that nobody relies on it. For guidance, see What metadata types should I include for Gearset pipelines? If you later need a type back, see Adding previously missing metadata types into Gearset Pipelines.

If comparisons are still slow, see Troubleshooting slow comparison speeds.

Gearset copies (clones) your repository for comparisons, CI jobs and Pipelines. Gearset caches repositories to reduce this, but larger repositories still take longer to work with. Repositories with large files, a lot of history, or a very large number of files are the slowest.

Keep your repository to Salesforce metadata. Avoid storing large files such as data exports, documents or build output in it.

Where your repository is hosted also matters. With a self-hosted Git server, the speed of your server and its network connection directly affects how long Gearset takes to work with your repository. Cloud-hosted providers such as GitHub, GitLab, Bitbucket and Azure DevOps are generally faster. If you're on a self-hosted server and your Pipeline is slow, this is likely to be a contributing factor. Moving to a cloud-hosted provider is a bigger decision with other benefits and security trade-offs, but performance is worth weighing up as part of it.

If you're already doing everything in this article, your Pipeline is running about as efficiently as it can. Nice work.

Some of the time that's left is the cost of doing things safely. Before anything reaches your org, Gearset validates it, checks it against what's already there, merges it with your team's other work and records it in Git. Skipping those steps would be quicker, but it would make it much easier for a broken change to reach production, and fixing that takes far longer than waiting for a validation.

The rest is down to Salesforce. Validations, deployments and Apex tests all run on Salesforce's servers, so their speed is outside Gearset's control.

It's also worth looking beyond the Pipeline. Run time is often a small part of how long a change takes to reach production. A Value Stream Mapping (VSM) exercise, where you map every step a change goes through from idea to release, shows where changes actually wait, for example on reviews, approvals or testing, and which steps could be automated alongside your Pipeline settings.

If something still seems slower than it should, or you have any questions, get in touch through the in-app chat. We're always happy to help.