Salesforce did their job and provided a helpful walkthrough including a sample Jenkinsfile, but in my experience, that was not enough.
I realised this was not enough while assisting on migrating projects for customisation and managed packages at the company I work for — ClaimVantage — and we felt that we should address the following:
- Avoid duplication (we started with 76 lines but quickly jumped to 171 lines and mostly was performing the same tasks)
- Simplify testing against multiple organisation configurations (really useful for ISVs like us)
- Easy to understand (developers should be able to understand what is happening during the build quickly)
We created a Shared Library for Jenkins that can solve the problems mentioned above and as a bonus helped us to drive some standards (such as simplifying the installation of managed packages, reporting multiple test executions, etc.).
Look below how simple that can become:
The library is called Salesforce DX — Jenkins Shared Library and is open-source, which means you can use it today on your projects: if you are an ISV, a Customer or a Consultant.
The build from the image above contains six different configurations, and they are all executed in parallel.
My next plans for the library are (feel free to join and propose new changes):
- Second-generation packaging.
- Retrieve package installation keys from Credentials using a pattern.
The main aim of this article is to spread the word about the SFDX — Shared Library. I would love to know if people would like me to write more articles on challenges we faced and how solved some of them, and how to use the library in more complex scenarios such as creating communities, setup platform encryption, etc. Let me know in the comments below!