Salto offers several capabilities practicing Continuous Integration and Continuous Delivery/Deployment.

Teams looking to use Salto for CI/CD may have questions such as:

To answer these questions, we first need to define some concepts.

The concept of SOT varies from organization to organization. In Salto, we define SOT as the following:

To achieve this version of SOT, Salto employs four different mechanisms:

The Salto environment itself serves as an up-to-date blueprint of your application configuration. You can search your configuration, find hardcoded values, and inspect dependencies using the Explore feature. Learn more here.

This helps answer the question “What is currently implemented in Production?”, for example.

In this way, the Salto environment itself becomes part of the SOT.

Your application configuration is fetched on a defined schedule. With every fetch, we detect changes that have been done, and we apply them to your Salto environment.

These changes can be analyzed to understand what changed since your last fetch, and can also be committed to a Git repository using our Audit feature. Learn more here.

Salto stores your application configuration in the NaCl format. After every deployment, you can push the latest changes to the NaCl files to your Git repository (referred to as “the NaCl repo” moving forward). This is the same repo mentioned in the above step. This way, the NaCl repo captures all changes done to your application, those made via deployments through Salto, and those captured by the periodic fetch.

This provides a level of detail on what has changed, by who, and when, that is difficult to achieve without Salto.

Finally, Salto offers the ability to receive email or Slack notifications in near real-time when a change is done in your application configuration. Learn more here.

In short, Salto offers several features, both in the app itself and in an external NaCl repo, that provide a complete picture of your business application, its current state, and changes made to it.

These features, combined, provide a powerful source of truth mechanism.

As explained in Salto's Git Branching Strategy, Salto does not use typical Git branches for its deployments and pull requests.

Instead, Salto uses a combination of Git-based deployments and environment-based deployments to allow users to automate actions such as deployments, code reviews, etc.

So, when using Salto for CI/CD without a pre-existing SFDX/SFD repo, you don’t need to think about Git branches at all. We manage that complexity behind the scenes.

If you are using an existing repo, read the next section.

If your team has an existing SFDX/SFD repo, you can continue to use it along with Salto.

Before we explain how this works, it’s worth mentioning that in most cases:

With these points in mind, a common question that arises is how to make your existing repo become the source of truth. As explained earlier, Salto uses different features to provide a complete view of your environment. We encourage you to adopt this new way as we are confident it provides the best version of the source of truth possible.

Salto can work alongside your existing repo; however, the most accurate source of truth will be the NaCl repo and the Salto environment.

With this out of the way, here’s a high-level approach for using Salto with an existing repo:

1- Use your existing SFDX/SDF repo to track changes in lower environments, i.e your Development sandbox and an Integration sandbox

2- Use feature branches, along with pull requests (PRs), to commit changes to the main branch

3- If desired, use CI jobs to use existing libraries that integrate with SFDX/SFD. For example, you can create a CI job in GitHub Actions that runs a validation deployment and static code analysis when a pull request is opened.

4- At some point during this process, you will handoff the deployment to Salto. This can be done via CI job using our CLI, or by creating a deployment from the Salto app and providing the URL of the pull request.

5- From here on, Salto can be used to promote the changes to higher environments, such as UAT, Staging, and Production.

These promotions can benefit from our CI capabilities, to allow you to gate the deployment or automatically deploy to the next environment.

6- When you deploy to Production, use our “Push to Git” functionality to commit the changes to the nacl repo.

In short, your existing repo is used to manage deployment activities in lower environments (typically dev and integration sandboxes), and Salto is used to promote this and other deployments (made by admins using Salto) across the pipeline.

This process does bring up some interesting questions:

How are admin changes, made through Salto, supposed to be integrated back in my original repo?

As mentioned earlier, in most cases, the original repo already contains a subset of the metadata of your application, and this is true whether you use Salto or not.

After a production deployment, you should use the Push to Git functionality to push those changes to the NaCl repo, which also contains changes captured by the periodic fetch.

There’s no standard mechanism to reflect some of these changes back into your original SFDX/SDF repo.

Some teams may want to implement a retrieval mechanism, whereby after a production deployment, you retrieve the metadata from production and commit it back to the original repo.

Does this mean I need to manage two repos?

If you want to continue using your existing repo, yes, you will have two repos: the original one, and the NaCl repo.

For the most part, this shouldn’t introduce too much complexity. The original repo is used to manage development activities in lower environments, while the NaCl repo provides the ultimate source of truth and allows for automation and approvals.