Salto for
NetSuite
Articles
SHARE
Sagi Bracha
March 12, 2025
5
min read
Managing NetSuite customizations efficiently requires a structured release process that ensures quality, collaboration, and minimizes risks. A well-defined release process improves visibility, tracks changes, and enhances coordination among teams. This guide outlines how to implement a practical and scalable release process tailored to NetSuite environments using Salto.
At the core of establishing a structured release process with Salto lies Git. Integrating Git is what enables a dev-like release process. It allows ongoing tracking of changes, structured review and approval via pull requests (PRs), automation (CI/CD), and advanced capabilities like rollbacks and reverts. Key benefits include:
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.
When deploying changes via Salto a pull request is automatically created, and all relevant changes are committed. To maintain an accurate representation of the configuration in a Git branch, Salto merges the change into the environments’ 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 environment. 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.
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 promoting using Salto:
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.
In this example, the release pipeline consists of a development environment, UAT environment and production (see image). Production and UAT are linked to a Git branch with PRs enabled, ensuring that every deployment to these environments is associated with a pull request.
Bringing a change into the pipeline
When an admin/dev is working on a task/feature, they start with making changes in the development sandbox and then deploying those changes to UAT.
They can create a “compare and deploy” type deployment from their development sandbox to UAT using Salto. In this case Salto automatically creates a PR targeting the UAT 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 UAT branch using Git and create a feature branch. Then, they can edit it using a development environment (such as VS Code with the SDF toolset), and once ready, they can create a Pull Request (PR) for the UAT 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 UAT are promoted to production via Salto. Users may choose to promote together one or more deployments. For example, when there is more than one deployment 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 implementation in production. If conflicts are detected - Salto flags them and allows the user to easily resolve them via the UI.
Deployment to production will also have a PR linked to it. Naturally the validation and approval processes required for production can differ from the ones required for UAT.
Promotion in Salto can also be automated - by leveraging the Salto CLI with your CI server, you can automatically prepare a promotion (or even deploy) changes to higher environments in the pipeline.
By using Git and integrating with CI tools, Salto helps NetSuite teams establish a dev-like release process with CI/CD practices that improve reliability and efficiency. Book a 1:1 session with our DevOps experts or try on your own with our free trial.
Salto for
NetSuite
SHARE
Sagi Bracha
March 12, 2025
5
min read
Managing NetSuite customizations efficiently requires a structured release process that ensures quality, collaboration, and minimizes risks. A well-defined release process improves visibility, tracks changes, and enhances coordination among teams. This guide outlines how to implement a practical and scalable release process tailored to NetSuite environments using Salto.
At the core of establishing a structured release process with Salto lies Git. Integrating Git is what enables a dev-like release process. It allows ongoing tracking of changes, structured review and approval via pull requests (PRs), automation (CI/CD), and advanced capabilities like rollbacks and reverts. Key benefits include:
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.
When deploying changes via Salto a pull request is automatically created, and all relevant changes are committed. To maintain an accurate representation of the configuration in a Git branch, Salto merges the change into the environments’ 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 environment. 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.
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 promoting using Salto:
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.
In this example, the release pipeline consists of a development environment, UAT environment and production (see image). Production and UAT are linked to a Git branch with PRs enabled, ensuring that every deployment to these environments is associated with a pull request.
Bringing a change into the pipeline
When an admin/dev is working on a task/feature, they start with making changes in the development sandbox and then deploying those changes to UAT.
They can create a “compare and deploy” type deployment from their development sandbox to UAT using Salto. In this case Salto automatically creates a PR targeting the UAT 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 UAT branch using Git and create a feature branch. Then, they can edit it using a development environment (such as VS Code with the SDF toolset), and once ready, they can create a Pull Request (PR) for the UAT 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 UAT are promoted to production via Salto. Users may choose to promote together one or more deployments. For example, when there is more than one deployment 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 implementation in production. If conflicts are detected - Salto flags them and allows the user to easily resolve them via the UI.
Deployment to production will also have a PR linked to it. Naturally the validation and approval processes required for production can differ from the ones required for UAT.
Promotion in Salto can also be automated - by leveraging the Salto CLI with your CI server, you can automatically prepare a promotion (or even deploy) changes to higher environments in the pipeline.
By using Git and integrating with CI tools, Salto helps NetSuite teams establish a dev-like release process with CI/CD practices that improve reliability and efficiency. Book a 1:1 session with our DevOps experts or try on your own with our free trial.