Embrace the power of DevOps to manage Salesforce Application Lifecycles
DevOps should be an important part of every Salesforce application lifecycle. But how? Let’s begin by defining what is DevOps.
At a high level, DevOps is the collaborative work of development (dev) and operations (ops) engineers — two groups that have traditionally been siloed from one another. The partnership works to automate and integrate the processes between them, which leads to building, testing, and releasing software faster and more reliably. A major feature of DevOps is the concept of continuous development, which can be broken down into three separate processes (see figure 1).
Continuous integration (CI) helps developers integrate their code into the master branch of a shared repository. Every time a developer pushes their code, the code is automatically deployed to a scratch org and unit tests are run. If any unit test fails, the code will not be pushed to the version control system.
Continuous delivery (CD) automates the process of building, testing, and deploying new code into a staging sandbox. Any successful push to the master branch will deploy the code to the staging sandbox after automatically running acceptance tests.
Continuous deployment is similar to continuous delivery, but it will also automatically deploy the code to production.
The CD process can be mapped onto the Salesforce application lifecycle in three steps (see figure 2):
- Code can be deployed to different scratch orgs and sandboxes using CLI or VS Code.
- The source of truth for the code is stored in a version control system.
- The lifecycle ends when the code is delivered to production.
CI/CD tools
The first step in enabling Continuous Development is to pick a tool. There are many product agnostic CI/CD tools available to choose from including Jenkins, Travis CI, Circle CI, Gitlab CI/CD and Github Actions. There are also some CI/CD tools built specifically for Salesforce, including Copado, GearSet, and Flosum. Salesforce has also introduced its own tool, Salesforce DevOps Center.
If you choose a product agnostic DevOps tool, you will need to write a script, which will run after the code is pushed to the code base hosted in Git. Using a YAML file is a recommended solution for writing the script, and it will work with most DevOps tools.
Here’s an example of a script for CI:
script:
- sfdx force:org:create -v HubOrg -s -f config/project-scratch-def.json -a ciorg — wait 4
- sfdx force:org:display -u ciorg
- sfdx force:source:push -u ciorg
- sfdx force:apex:test:run -u ciorg — wait 10
- sfdx force:org:delete -u ciorg -p
These commands will create a temporary scratch org, push the code to the scratch org, run the test classes, and delete the scratch org. When defining the script for CD, you can modify it to use force:package:version:create and force:package:install instead of force:source:push and deploy the code to a sandbox instead of a scratch org.
Product agnostic tools
Jenkins is a self-contained, open-source automation server that can be used to automate all sorts of tasks related to building, testing, and delivering or deploying software. Jenkins can be installed through native system packages, Docker, or even run standalone by any machine with a Java Runtime Environment (JRE) installed. The pros include that it is open source and free, there are many available plugins, and it is flexible to create jobs in freestyle or pipeline. The cons include that it can be difficult to configure, and it does not have the best error reporting.
Travis CI is a hosted CI service used to build and test software projects hosted in GitHub and Bitbucket. It focuses on allowing users to quickly test their code as it’s deployed. When a change is detected, Travis CI can provide feedback on whether the change was successful or not. Open-source projects are free to use, and failed build have detailed error logging. Travis CI originally relied on GitHub, but now supports other git products, including Bitbucket, GitLab, and Assembla.
Gitlab CI is another tool to manage the DevOps process. The benefits are that it is an all-in-one tool that includes git, continuous development, and more. CI/CD pipelines are used to manage the process and every commit or push will trigger the pipeline, which has three built in stages: build, test and deploy. Gitlab has a free tier, but it can execute the CI code very slowly.
Salesforce-specific tools
The benefits of using a Salesforce-specific tool is that no code is needed to configure CI/CD. All the configuration can be done through the user interface, which makes it admin friendly. These tools also have built-in features such as rollback, quality gates, and auto back deployment.
Gearset is an example of a release management tool built for Salesforce. Unlike some of the other tools, you don’t install this tool into your Salesforce org. Instead, you use a cloud-based site that connects to Salesforce. Gearset allows you to easily visualize the differences in metadata between orgs and/or git branches. Some of the pros are that you can manage the entire pipeline through the user interfaceand the tool can be used with or without git. There are also a few cons, including automated QA scripts require an integration with Jenkins to run, and a connection with an ALM tool such as Jira requires some additional setup.
Copado provides low-code DevOps and testing tools for Salesforce. The tool has been around since 2013. Copado can be installed as a managed package to your Salesforce production org. The visualization of the pipeline with what user stories need to be promoted or back-promoted makes it very easy to keep each org up to date. Automated testing can be integrated with Copado using their own tool or Selenium, but not other testing tools.
Salesforce DevOps Center has been GA since December 2022. It is not as mature as the other comparable tools that have been in the market longer, but it can provide the basics of managing your releases with source control — all from within Salesforce.
With DevOps fully integrated in your Salesforce development lifecycle, teams can expect to save time, reduce integration problems, and catch more bugs early on.
