Why is my CI deployment taking longer than expected?

Today’s post is brought to you by our good friend Eric Kintzer, Salesforce Architect and one of Gearset’s Community Advisors.

Assumption: you’ve configured an automatic deployment from source control to your continuous integration (CI) org.

When deploying in this situation, the developer wants the deployment to run as quickly as possible. When it does not, the developer’s workflow is interrupted and, if not addressed, results in repeated frustration every time one commits to master (such as after a code review of a pull request).

So, why might this CI deployment be taking too long, and what can I do about it?

There are a few reasons as to why your CI deployment may be taking longer than you’d like, but luckily there are a few things you can do to mitigate this wait time.

1. You are comparing more metadata API objects than are really needed for your CI use case

For example, do you really need to deploy Custom Object Translations or Reports just to verify that your Agile stories will successfully “build” in the CI org? If this sounds familiar, then just strip down which metadata types you’re comparing (via the metadata filter settings under “Edit job...”) and only include the types you actually need. This will cut away the noise and speed up the deployment.

2. The Apex tests which you have written over the years take too long to run

Gearset uses the Metadata API to run Apex tests, and these run serially. Go through your codebase and remove redundant tests, and better still, for orgs that have adopted good design patterns like Andrew Fawcett’s Force.com Enterprise Architecture, adapt your test methods to be more unit test-oriented. Using ApexMocks encourages you to write more composable, modular code, which will only become more important as teams start to adopt 2nd generation packaging, and has the added benefit of saving on test run time.

3. You have the right Metadata API objects configured in the CI job filter, but your source control metadata version is not the same as the CI target org’s version

Okay, this isn’t strictly about performance, but metadata and API versioning is an important consideration. For example, your metadata in source control is at V43.0 but the CI org is at V45.0 (and you are using default highest common version). If you include Custom Objects in your CI deployment metadata filter (which you pretty much have to anyway), you discover that SFDC changed the XML for a Custom Field between V43.0 and V45.0 when it comes to encryption. The <encrypted> property works through V43.0 (your source control) but as of V44.0, the new property is called <encryptionScheme>. Gearset sees your Custom Field as being different and includes it in the deployment package — even if you made no change to the field at all as part of your Agile story.

Of course, Gearset will use some tricks to try to identify the API version your version-controlled metadata is from — reading the package.xml version, and looking for specific metadata types and changes that correspond to specific API versions — but these techniques might not be successful, depending on the metadata you’re storing in your repository. For the avoidance of any doubt and to ensure you’re not attempting to deploy anything unintended, update the version number in your package.xml, or your CI job configuration in Gearset, to be certain that you’re deploying your metadata with the right API version.

Hopefully this gives you a little context as to how you can improve your CI setup. If you haven’t already, try Gearset’s CI features for yourself or download our CI/CD ebook to discover how you can improve your CI/CD pipeline.