CI/CD is a development practice where code, configurations, or metadata changes are automatically tested, integrated, and deployed through an automated pipeline.

Proper CI/CD practices add quality gatekeeping, improve collaboration, simplify troubleshooting, and enable quick revert of faulty changes. While team velocity increases, individual deployments may take slightly longer due to the added rigor.

This guide outlines how to implement a practical, scalable pipeline tailored to your needs using Salto. You should begin with a simple pipeline and slowly expand its capabilities where they matter most.

Your pipeline will include a series of shared environments (Salesforce organizations) leading up to the production environment. A typical sequence might be SIT -> UAT -> Production.

Changes can enter the pipeline in two ways:

Salto enables users to deploy changes in multiple ways:

After changes are deployed and verified using Salto in one environment, they are promoted to higher environments. For features involving several contributors (can be both admins and developers), changes from multiple team members can be promoted together.

Urgent fixes may bypass the standard pipeline via a dedicated hotfix environment or by deploying directly to production without a promotion deployment. Afterward, these changes should be promoted back to lower environments in the pipeline to ensure the various environments’ baselines are aligned.

Periodic fetching is enabled by default in all environments. Users can set it to run hourly, daily, weekly, or disable it if needed. This ensures that Salto automatically detects any changes made in Salesforce.

Salto’s Change Log tab tracks all modifications made within a single environment, regardless of whether they were deployed using Salto or identified during the periodic fetch. This ensures comprehensive visibility into all changes for better management and oversight.

The pipeline’s environments can be connected to a Git repository. Once connected, all changes made to an environment are automatically pushed into Git. This integration ensures:

Below is an explanation of the recommended branching strategy and how to set the pipeline in Salto.

In addition, you can find out in this article how to protect deployment using Pull Requests, connect changes to business requirements tickets, and automatically run validations before deploying to Salesforce.

Salto employs a branch-per-environment approach. Each environment in the pipeline has a dedicated long-living Git branch. There is no need to have personal dev environments in Git (they can be if the team wants).

Each feature has a dedicated short-living feature branch (or branches). Salto automatically creates the feature branch from the target environment’s branch for each deployment created in the Salto UI. This branch holds all the changes related to the feature. Using Salto, those changes will be applied to the target environment.

Team members can create a feature branch using VSCode or any other tool. They should branch from the target environment branch they wish to deploy, typically the lowest shared environment (e.g., the sit branch). Then, they should create a Salto deployment based on the feature branch Pull Request.

After the deployment finishes, Salto merges the changes into the environment branch. Before merging, failed parts of the deployment are reverted in the feature branch, ensuring that the org is accurately represented in the branch.

When a feature is promoted to a higher environment using Salto's promotion deployment, a new promotion branch is automatically created. This branch is created from the promotion deployment target environment branch and will contain the same changes as the original deployment(s).

It is recommended that multiple features be promoted together. This allows teams to set a release process that pushes all recent features to production. In this case, a single feature branch will represent the release, including all changes from the numerous original deployments.

In addition, Salto provides tools to detect and resolve semantic conflicts during deployments, ensuring changes from multiple contributors don’t disrupt each other. Learn more.

Salto will now automatically sync environment configurations with their branches, ensuring:

Salto improves traceability by linking changes to business requirement tickets. Including ticket IDs in the deployment name directly connects changes and their purpose. As the deployment name (and description) are the basis for the deployment commit message, the link is shared across Salto, Git, and the ticketing system.

Salto Administrators can enforce commit message patterns to structure deployment titles and descriptions to prevent commits that can't be traced back to tickets. Learn more here.

Use Pull Requests (PRs) to introduce gatekeeping for specific environments. This enables:

Salto integrates with CI tools to run automated jobs, for example:

Learn more here.

In our example, a Salesforce admin named Alex works on a new feature with a Salesforce developer named Dianne.

Their team has a pipeline of two environments:

Alex uses his personal sandbox to develop his part of the feature. Once done developing, he selects his changes to be deployed to UAT using Compare & Deploy in the Salto UI. Salto automatically creates a feature branch and a PR for the uat branch. A Github action will run tests on the PR, and Dianne can review its content.

At the same time, Dianne developed her part using VSCode and created a PR for uat branch using git CLI. Now, a GitHub action will identify this new PR is not attached to a Salto deployment and will create a new Salto deployment in addition to running Salesforce tests.

Alex figured a part was missing, so he developed it in his sandbox and selected it in Salto UI. The changes to the Salto deployment are reflected in the existing GitHub PR, and validation will run again automatically.

Dianne received a review comment, fixed her code, and pushed changes to the PR. The related Salto deployment has been updated, and validation will run again.

When the PRs are mergeable, Alex and Dianne will deploy their changes to the UAT environment, and Salto will merge the changes to the uat branch.

The stakeholders tested the new feature in the UAT environment and found some bugs. Alex and Dianne developed fixes for the bugs in their sandbox and deployed the fix to UAT using Salto. Now, the stakeholders are happy.

Alex creates a new promotion deployment in Salto UI containing his and Dianne's original deployments and bug fixes deployments. Salto automatically creates a promotion branch and PR for the main branch, containing combined changes.

Dianne reviews the PR, and after it is successfully validated and approved, Alex will deploy the changes to production together.