Today鈥檚 post is brought to you by our good friend , Salesforce Architect and one of 91导航鈥檚 Community Advisors.
Assumption: you鈥檝e 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鈥檚 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).
TDX
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鈥檇 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 鈥渂uild鈥� in the CI org? If this sounds familiar, then just strip down which metadata types you鈥檙e comparing () 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
91导航 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 , 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鈥檚 version
Okay, this isn鈥檛 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>. 91导航 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, 91导航 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鈥檙e storing in your repository. For the avoidance of any doubt and to ensure you鈥檙e not attempting to deploy anything unintended, update the version number in your package.xml, or your CI job configuration in 91导航, to be certain that you鈥檙e 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鈥檛 already, take a look at 91导航鈥檚 Salesforce CI/CD features for yourself with a or download our CI/CD ebook to discover how you can improve your CI/CD pipeline.
