CI/CD is the practice of automating the testing, integration, and deployment of changes to ensure quality and collaboration, and simplify troubleshooting. While it adds rigor to deployments, it ultimately boosts team efficiency and reduces risks. This guide outlines how to implement a practical, scalable CI/CD process tailored to your needs using Salto.

Git integration: The foundation of CI/CD in Salto

Salto’s Git integration ensures that every Salesforce environment has a clear, up-to-date record of its configuration. This makes managing changes, tracking deployments, and collaborating across teams much easier. Key features include:

1. Comprehensive change documentation

Salto ensures a consistent audit trail and simplifies troubleshooting.This is achieved by enabling to link an environment with a Git branch that holds a textual representation of its configuration. Each Salto deployment has a representation in a feature branch that is merged into the environment branch once changes are deployed. If changes are done directly via the service UI, Salto pushes them into the environment branch once fetched.‍

2. Integration with ticketing systems‍

Changes can be directly tied to business requirement tickets by including ticket IDs in deployment names. This creates a straightforward link between what was changed and why, improving traceability and accountability.‍

3. Collaborative Pull Requests

Teams can use pull requests (PRs) for deployments, enabling:

• Peer reviews and structured approval workflows.
• Branch protection rules to ensure only validated changes are deployed.
• Compatibility with both Git workflows and Salto’s deployment tools, bridging the gap between admins and developers.‍

4. Automation and validation

Salto integrates with CI tools to automate critical tasks:

• Triggering validations and Salesforce-specific tests when a PR is created or updated.
• Enforcing branch protection rules that require tests to pass before deployment.

Branching strategy: Bringing structure to deployments

Salto uses a branch-per-environment approach, aligning with CI/CD best practices while addressing Salesforce’s unique needs. Here’s how it works:‍

1. Dedicated branches for each shared environment

Each shared environment in your pipeline (e.g., Dev, UAT, Prod) has a corresponding Git branch. This ensures consistent tracking of changes as they move through the pipeline.
Learn more about developing in shared environments vs. personal sandboxes here.

2. Pull Requests for deployments

When deploying changes via Salto a pull request is created for the deployment and all relevant changes are committed. Alternatively, developers using SFDX and VSCode can start with creating a PR targeting the environment branch and create a Salto deployment from it. This opens the door to a unified approval process for admins and devs that can be configured using Git branch protection rules, as well as running automated jobs (like validations).

In order to maintain an accurate representation of the org configuration in a Git branch, Salto merges the change into the org branch only after the deployment. This means that only successful deployments (or successful parts of deployments) are merged, ensuring the Git branch truly represents the org. Salto handles failed parts of deployments by automatically pushing another commit to the feature branch, reverting those failed parts of the deployment before the merge.

3. Promotion between environments

Changes are promoted from one environment to the next using Salto. It is possible (and recommended) to combine multiple deployments together into a single promotion, which allows you to operate more efficiently in terms of validations when promoting changes to the higher environments. When combining deployments for promotion, you will be able to choose the changes that have been approved for promotion.

When promoting in Salto:

• A new promotion branch is created from the target environment’s branch.
• Promoted changes are committed, and a PR is created to merge them into the target branch.
• Tests and validations ensure consistency and stability during the promotion process.
  

4. Conflict resolution

Salto includes tools to identify and resolve conflicts during deployments or promotions, ensuring that changes from multiple contributors don’t overwrite or disrupt each other.

A Typical Salesforce CI/CD workflow with Salto

In this typical example, the deployment pipeline is comprised of personal dev/admin sandboxes, SIT org, UAT org and Production (see image), while Production, UAT and SIT are linked to a Git branch and deployment PRs are enabled, meaning that any deployment to those environments will have a PR linked to it.

Bringing a change into the pipeline

When an admin/dev is working on a task/feature - their goal is to bring those changes to the first shared environment (SIT in this scenario). This starts with making changes in their personal sandbox and then creating a deployment of those changes to SIT. 

They can create a “compare and deploy” type deployment from their personal sandbox to the SIT using Salto. In this case Salto automatically creates a PR targeting the SIT branch. This mode is intuitive and easy for users who don’t want to handle Git directly (as Salto takes care of everything for them). 

Alternatively, developers can directly branch out of the SIT branch using Git and create a feature branch. Then, they can edit it using a development environment (such as VS Code with the SFDX toolset), and once ready they can create a Pull Request (PR) back to the SIT branch and initiate a Salto deployment from that PR.

This means that whether you’re using a Git-first approach or allow Salto to take care of Git operations for you - all deployments always have a PR linked to it, and a consistent validation and approval process.

Promoting a change up the pipeline

Changes deployed to SIT are promoted to UAT via Salto. Users may choose to promote together one or more deployments, for example, when there is more than one deployment that is connected to one feature that is ready for promotion. Upon the initiation of the deployment(s) promotion - Salto will check that promoted changes are not conflicting with the current production configuration. If conflicts are detected - Salto flags them and allows the user to easily resolve them via the UI. 

The same as in the case of SIT, deployment to UAT will also have a PR linked to it (with the same alternatives of creating the PR as described above). Naturally the validation and approval processes that are required for Production can differ than the ones required for SIT. 

Promotion in Salto can also be automated - by leveraging the Salto CLI with your CI server, you can automatically prepare (or even promote) changes to higher environments in the pipeline. 

‍

Salto helps admins and developers collaborate in a way that does not require Git knowledge from less technical users nor does it require devs to change their infrastructure, processes or tools they use. 

By using Git and integrating with CI tools, Salto helps Salesforce teams adopt CI/CD practices that improve reliability and efficiency while accommodating the unique characteristics of Salesforce environments. Book a 1:1 session with our DevOps experts or try on your own with our free trial.