SuiteScript Operations - Environmental Drift

Created: November 16, 2020

"Environmental Drift" is how I describe the phenomenon wherein the code and objects you've created for a SuiteScript project will spread across multiple NetSuite environments (Production, Sandboxes, Release Preview) and, the more time passes, the further those same elements will begin to differ - or drift - both from each other and from what is committed in your version control repository.

A handful of you may have seen this information already; know that I appreciate your feedback 😃

⚠️ Before going further, this solution assumes your team is using a version control system with branching capabilities (e.g. git) and that they are using the SuiteCloud Development Framework (SDF). If you are not using these already, you cannot go wrong investing some research and effort into them. Individually, each is excellent bedrock on which you can build a more effective SuiteScript team. Combined, they form a springboard to faster development cycles, high quality standards, and efficient automations.

The Problem

The causes of environmental drift are numerous, and its effects are insidious. Perhaps a developer moves a Script from Testing to Released but forgets to update the repository; or an Administrator changes the Permissions list on a Custom Record without notifying developers; or a Sandbox refresh throws a wrench in everything and grinds development to a halt.

Inevitably, the objects which have drifted cause issues within the NetSuite account. Releasing new changes becomes impossible until the issues have been fixed. Troubleshooting becomes more complicated as there are now untracked changes within the environment. You can easily get caught thrashing back and forth between fixing and releasing without actually making progress on anything.

The First Pass

To get ahead of this problem, many teams attempt to force their main branch to "always match Production" because "the account is the source of truth!". They may additionally force other branches to match additional Sandbox environments. This approach is conceptually fine, but can be extremely disruptive to development in practice. Unverified changes - some not even made by members of the development team - get blindly committed into the normal flow of development simply because that's what someone put in the NetSuite account - whether it's correct or not.

My Approach

A slight modification to this approach can make all the difference. Instead of using branches which are tightly coupled with your team's typical workflow, use branches which are completely detached from the normal development cycle. Create one such branch for each environment, and name it appropriately (Production, Sandbox1, etc). Never merge these branches into any other branch.

The Process

The mechanics are best illustrated with an example. We have a git repository with a main branch which contains all of our previously completed, reviewed, tested, and released code and Object definitions. We're about to release into Production our latest significant work, but before we merge that work into main, we can:

1. Switch to the Production branch and download all relevant code and Objects for the project from Production using SDF's object:update command (Not using SDF? Download the relevant source files from the file cabinet. You won't be able to easily compare Object definitions).
2. Commit the downloaded project on the Production branch to reflect what is currently in the account.
3. Compare the Production branch to the main branch using git diff (or any other file comparison tool).

This will show us exactly which files and Objects in our repository have drifted from their counterparts in Production before we deploy and find out the hard way.

If any drift is detected:

1. Assess all drifted objects and files.
2. Incorporate any appropriate changes into our release work and re-test.
3. Merge release work into main.
4. Deploy main to the Production account using SDF's project:deploy command.

This quick process will prevent hours or even days of lost progress due to a bad deployment and will enable you to have much shorter, more consistent deployment windows.

Have questions?

Grab some free time on my calendar and let's talk.

HTH

-EG