Reader Response: Handling Deployment Collision in NetSuite

Created: February 22, 2021

I've been battling a fierce case of writer's block all morning (all weekend, actually), trying to figure out what to send you today. Precipitously, your fellow Sustainable SuiteScript reader Eric Schultz wrote in on his horse to save the day with an excellent question about deployment collision when working with multiple developers. I can't help but laugh at the collision in our names, as well.

Here's Eric's question, followed by my response (name, question, and response all shared with permission):

Hey Eric

Love the podcasts, and keep up the great content / work. Recently a topic came up in my environment which kinda piggy backs off an older podcast you did " Episode 5: Development Tools". While I too use Webstorm / PHPStorm and even testing with IntelliJ IDEA from jetbrains with the Netsuite IDE plugin, we have run into the issue of code overlapping between multiple developers. The issue we have is the IDE plugin uploads everything in your project whether or not you touch /edit a file. We are working to address that issue with shrinking down local file&folder workspaces to only include what a developer is working on. But this made us wonder what are other development teams doing when multiple developers are working on the same Netsuite Instance?

We do use bitbucket for source control for final commits of code, but when it comes to the rapid development and testing of scripts in netsuite this is where we have the issue. Any thoughts or insights on how larger development teams (or even teams 2 or more) would be interesting and is appreciated.

Great question!

There are many potential causes of developers stepping on each other, and I don't have enough context to know which one(s) you're running into specifically, but I'll walk through my thoughts on avoiding collisions when deploying to NetSuite.

Collision typically occurs because you haven't done enough separation of concerns within your task planning, your project structure, or your software architecture (or perhaps all three).

The official SuiteScript IDE plugins (WebStorm, Eclipse, and soon VSCode) are running SDF under the hood to deploy code to a NetSuite account. SDF allows you to define Projects, where a Project is a collection of Configuration Settings, custom Objects, and source code files. Within each Project, you can define external dependencies (on other files, Objects, features, etc) in the Project's manifest.xml file, and you can define exactly what gets deployed in the Project's deploy.xml file.

The first potential mitigation, then, is for your developers to use their Project's deploy.xml file to explicitly define the Objects and files which get deployed as they work. This is workable, but it's very manual and potentially error prone.

If your developers are not leveraging branches in source control to isolate their work, this modification of deploy.xml presents an additional problem. Without branches to isolate the changes to the file, developers will constantly be overwriting each others deploy.xml changes in their commits. With branches, the concurrent changes to deploy.xml will likely bring up many merge conflicts. Consider a second collision mitigation by implementing a branching scheme for your source control process and by ignoring deploy.xml within your repository(ies).

If you only have a single SDF Project containing all of the customizations of an entire NetSuite account, then this sort of collision becomes extremely likely, and you won't have much recourse other than the manual manipulation of deploy.xml. To reduce the amount of collision, you can break up your monolithic SDF Project into smaller Projects. Rather than trying to manage all Customizations with a single Project, consider a third mitigation of using a Project to manage one specific Feature or Customization within the account. This approach will separate the concerns of each Project and will reduce the deployment footprint for each one dramatically. I discuss some potential repository/Project layouts and my own preferences in this article.

If you do break up Projects along Feature lines, but you commonly have multiple developers working on the same Feature, then you will still see this same collision. They can still manually manipulate deploy.xml to control what gets deployed as they work, with the same caveats as before. A fourth mitigation, then, is to be more diligent in your task management and assignment such that developers are rarely working on the same feature - or if they are, ensure they are collaborating closely and working on the same source control branch so that their changes are shared instead of competing.

Lastly, in conjunction with this diligence in task management, take a look at your SuiteScript architecture. If you commonly have large source files with many uses that several developers need to touch (I'm looking at you, Sales Order Client Script and Invoice User Event!), then the likelihood of stepping on each other increases. The more you push your architecture towards small, single-purpose modules, the less likely collision becomes as developers are less likely to be touching the same module, and those modules will potentially split into different Projects per the second mitigation.

HTH

-EG