Skip to main content
All CollectionsIntegrating Git and CI/CD
Protecting Deployments with Pull Requests
Protecting Deployments with Pull Requests
Support avatar
Written by Support
Updated today

(!) Available in the Enterprise plan

Overview

Salto allows you to leverage your git provider by automatically attaching a pull request to deployment records. These pull requests capture all of the planned configuration changes in Salto deployments and allow you to:

  1. Comment, discuss and get approval from colleagues about the planned configuration changes

  2. Connect your preferred CI/CD tool in order to automate validations and deployments. You can further integrate any other external tool for additional use cases, e.g. static code analysis tools.

  3. Push and deploy additional NACL edits, made out of the Salto Platform

Enabling deployment pull requests

Salto can be configured to automatically create a pull request for any deployment record targeting a certain environment.

In order to enable this behavior, you will first need to connect your environment to a git repository and branch and make sure to turn on 'Deployment protection via Salto PRs'.



If your environment is already connected to a git branch, deployment protection via Salto PRs can be turned on via the version control section of the environment settings screen.

Deployment Pull Request LifeCircle

  • When deployment pull requests are enabled for an environment, Salto automatically creates a feature branch from the environment branch for any new deployment reaching the "deployments preview" state, commits the planned configuration changes, and opens a pull request to merge into the environment branch.

  • Any updates to the deployment preview (e.g., element selection changes or edits) are pushed to the feature branch, keeping the pull request aligned with the planned configuration changes.

  • The deploy operation in Salto remains disabled until the pull request is mergeable, based on the repository’s branch protection rules.

  • Once the deployment is completed, Salto automatically squashes and merges the pull request, ensuring the environment branch reflects the deployed configuration. Please make sure not to push or merge PRs to the environment branch outside of Salto.

Feature Branches Naming Conventions

In Salto, deployment feature branches follow a specific naming convention: salto/env/<envId>/deployment/<deploymentId>.

This pattern is critical because automations tied to Salto deployments are triggered when pull requests (PRs) are created or updated, but only for feature branch names starting with salto/env.

This ensures that only deployment-related actions activate these automations. PRs involving other types of changes should avoid this naming structure, as it’s reserved exclusively for deployments and not general modifications.

For more information, check out these resources:

Deploying additional edits using Pull Requests

Users can also use the created pull request to make additional edits to the deployed elements or support a classic "Find and Replace" use case. This can be used to perform advanced editing on your files - for example, replacing a value in many files, or introducing a large amount of new elements created by some internal script.

To include external edits in your Salto deployment:

  1. Clone the git repository to some local repo

  2. Checkout source branch of the pull request

  3. Perform your edits

  4. Commit and push these edits to your remote repo

Salto will automatically detect incoming changes, and will ask the deployer to pull these commits into the deployment.

When committing additional changes to Pull Requests, avoid force-pushing your commits as that may prevent Salto from pulling these changes properly.


Did this answer your question?