Sort by Topics, Resources
Clear
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Salto for

NetSuite

Articles

SHARE

Structuring a Scalable NetSuite Release Process

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.

Automate the way you migrate Jira configurations from sandbox to production

Git Integration: The Foundation

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:

  1. Comprehensive Change Documentation - Salto connects the NetSuite environment with a Git branch, that holds a textual representation of its configuration. This ensures a consistent audit trail and simplifies troubleshooting. Changes can get to the branch in two ways - A) Each Salto deployment is merged into the environment branch once changes are deployed. B) If changes are done directly via the NetSuite 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. Gating Deployments Using Pull Requests - Salto automatically creates pull requests for deployments and can be configured to block deployments if PRs are not approved. This enables forming a structured approval process that includes peer reviews and applying branch protection rules to ensure only validated changes are deployed.

  4. Automation and Validation - Salto integrates with CI tools to automate validation and testing before/after deployments.

Structuring Your Release Pipeline

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.

2. Pull Requests for deployments

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.

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 promoting using 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 NetSuite Release Workflow with Salto

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.

WRITTEN BY OUR EXPERT

Sagi Bracha

Marketing

Sagi is a Product Marketing Manager at Salto, overseeing Salto’s Jira, Salesforce and PLG business motions. Driven by data and audience insights, Sagi is excited about designing custom made, customer centric go-to-market strategies. Sagi also plays the keyboard in Salto’s band, and enjoys dancing and reading in her free time.

Sort by Topics, Resources
Clear
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Salto for

NetSuite

SHARE

Structuring a Scalable NetSuite Release Process

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.

What if Zendesk was 4x less work?

Request a Demo Get started with Salto

Git Integration: The Foundation

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:

  1. Comprehensive Change Documentation - Salto connects the NetSuite environment with a Git branch, that holds a textual representation of its configuration. This ensures a consistent audit trail and simplifies troubleshooting. Changes can get to the branch in two ways - A) Each Salto deployment is merged into the environment branch once changes are deployed. B) If changes are done directly via the NetSuite 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. Gating Deployments Using Pull Requests - Salto automatically creates pull requests for deployments and can be configured to block deployments if PRs are not approved. This enables forming a structured approval process that includes peer reviews and applying branch protection rules to ensure only validated changes are deployed.

  4. Automation and Validation - Salto integrates with CI tools to automate validation and testing before/after deployments.

Structuring Your Release Pipeline

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.

2. Pull Requests for deployments

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.

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 promoting using 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 NetSuite Release Workflow with Salto

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.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

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.

WRITTEN BY OUR EXPERT

Sagi Bracha

Marketing

Sagi is a Product Marketing Manager at Salto, overseeing Salto’s Jira, Salesforce and PLG business motions. Driven by data and audience insights, Sagi is excited about designing custom made, customer centric go-to-market strategies. Sagi also plays the keyboard in Salto’s band, and enjoys dancing and reading in her free time.