Through many years of work, we have defined the most efficient way of managing our development process from tools to specific testing practices. It helps us in our daily work, and we’d be glad to see it help others.
Development tools that automate Salesforce CI/CD
On average, CI/CD tools for any development environment can perform:
- Automatic launch of unit and end-to-end (E2E) tests before releasing the code to production. If these tests fail, the deployment doesn’t happen;
- Integration with code analyzers. They find duplicate code or code that doesn’t meet project standards, and scan for potential vulnerabilities.
There are a few types of CI/CD tools that we have tried out and figured out their pros and cons for our needs.
I. Self-hosted: Jenkins, TeamCity
The advantage of these tools is that the developers can fully control the environment they work in, and the price is relatively low – Jenkins is actually a free tool. Developers can also significantly expand the tools’ functionality with plugins.
At the same time, their main advantage is also their main disadvantage – the need to allocate valuable resources for the maintenance of this system. It’s often a separate person assigned to this, which significantly affects the price of use. Of course, you can delegate hosting those environments to other services, but then the advantages of the tools will no longer be so obvious.
II. Hosting platform: GitHub Actions vs GitLab CI/CD vs Bitbucket Pipelines
The biggest advantage of these platforms is that they can be integrated with many other services. For example, they immediately have a version control system (VCS) and can easily connect to Salesforce. They are also often closely related to ticket systems (Bitbucket with Jira).
All of those services give a certain number of free minutes per month to run CI/CD jobs. GitHub Actions provides 2000 free minutes, GitLab provides 400, and Bitbucket – 50 minutes.
Among the cons, we can highlight a rather low possibility of expansion, although the services are quite actively working on this functionality, and often at a rather high price. It can be a deal breaker if you do not have enough resources to free up.
We have found that GitHub Actions provides the best flexibility to extend the functionality through plugins. It even has its own marketplace filled with them. Bitbucket has limited extensibility and requires using custom Docker images.
III. Salesforce-specific tools: Gearset, Copado
A big plus of such systems is their close integration with Salesforce. The other advantage is their UI. These platforms show a visual representation of what exactly will be deployed to the org, and you can choose what you want to be deployed. There even is a revert of changes if something goes wrong.
The big con is that they are rather slow working, and often pricey. However, for big development teams that specifically need a built-in solution, it can pay off.
The CI/CD tool we choose for Salesforce development
We choose GitHub Actions. It’s integrated with GitHub, and with repositories, it’s quite convenient to manage CI/CD execution.
It offers a free plan with 2k minutes per month. For an extension, it has a good feature set, and since this tool is quite popular, there are already many different plugins to explore.
Minor tools for Salesforce static analysis
- Salesforce CLI – for deploying code to orgs, running tests, and building the package
- Understand by SciTools – for code validation according to the Salesforce code style
- Salesforce Code Analyzer (sfdx-scanner) – for checking the code for potential dangers
- ESLint – for validating LWC components
- WebdriverIO – for running end-to-end automation tests
Action points for pull requests
We create a working .yaml configuration file to run our CI/CD deployment. There, we indicate that it should be launched from the PR and that it will contain some alterations to the code. The script itself has a check for the PR status – its approval acts as a starting point for the deployment.
If the pull request has not yet been approved, there is no point in launching the CI/CD script, but then it checks for code validity. Then, when everything checks out clearly, the deployment of the code to the production or QA organization starts.
Packaging
To save GitHub Actions minutes, we run all the tests once a day. The package is sent for testing in the QA org after PR approval in the development branch. The package is managed by the Salesforce Code Analyzer, and it is fully automated, so no one interferes in the process.
It’s not always smooth, of course. Most of the issues arise when Salesforce releases updates and discontinues its support for older versions of the tools we use. And for everything else, there are rarely any critical problems. It’s because GitHub Actions runs on a Linux machine, so everything is supported natively within itself.
Deployment to production
Deployment to the production can be done in several ways. If it is not a big project (1-2 orgs), it is best to automate it with CI/CD.
If you have many customers with many orgs, then you need to control the process of deploying new code versions. This can be done manually – after the release of a new version of the package, you simply press the deploy button. We often deploy it for one client, wait a few days to ensure everything is okay, and then deploy it for the rest of them.
The next step for automation would be setting up pre-commit hooks to run ESLint and Salesforce Code Analyzer (sfdx-scanner) on developers’ PCs. This will speed up the code review, reduce the mundane work of the reviewers, and save up the free minutes provided by the tools.
