Expand your SuiteScript skills in the Sustainable SuiteScript community for NetSuite developers.

Hotfixes in git for NetSuite Developers

Created: February 3, 2025

After reading the article detailing my source control process, SuiteApp Developer Extraordinaire and Sustainable SuiteScript community member Darren Hill asked an astute question:

I read your "My git Process for SuiteScript in 2025" and have a question. It sounds like you let main get ahead of your code in NetSuite. What happens when you need a hotfix done, but are not ready to push main to NetSuite?

Here's how the conversation unfolded from there (all shared with Darren's permission):


Me:

main can get ahead, yes, but it should be rare. If it does consistently get too far ahead, then we have an operational problem, not a source control problem. Namely, we aren't releasing often enough.

In teams that really want to solve this problem with source control instead of consistent release cadences, we bundle up un-released features into Release branches. That Release branch does not merge to main until it actually deploys. We deploy it from main, but the merge happens immediately beforehand.

The tip of main is then always known to be the latest deployed version. In the case of a hotfix, it goes exactly as stated in the article. It's just a special case of a feature branch, cut from main, and then it gets to skip the Release branch.

This tension of not trusting main as Production, but also not wanting it to get too far behind, is a big part of why I love release trains for NetSuite development. I think they work really well in our space. Maybe less for SuiteApp teams? I'm not sure, I don't seem to get to work with SuiteApp teams ever.

I haven't explored that topic yet in writing, but I will soon.

(a few minutes later)

I realize I'm sort of dodging your question in my initial answer.

If main is ahead and I must release a hotfix, then I'm going to have to cut the hotfix branch from the last known deployment point, make the fix there, and deploy from the hotfix branch, making damn sure I only deploy precisely the changes I made [for the hotfix] - very likely manually deploying individual code blocks in the UI. Getting that hotfix back into main cleanly will probably involve some annoying reverts and re-reverts

I'm of the opinion that hotfixes should be painful as hell, lest they become the norm. If a team is regularly needing to hotfix, we have a big ol stinky ops smell somewhere else. The problem isn't our source code strategy.

Darren:

Love the answer. Clever use of tagging may help here too. We aren't in the Account Customization side, so our release management is more in line with traditional app development. I can see the challenge AC projects have.

Eric:

Oh I have a whole tagging approach I usually get into with teams. I'll be writing about all of this in the coming weeks (months?). [Account Customization] teams by default tend to release "randomly" when the client asks for it, or they stack up months of work to be released all at once on some magic go-live date.

Both are awful.

I try to push teams away from that as rapidly as possible.

Darren:

I'm sure you've spoken on it before, but what are your thoughts about naming your 'long running' branches after the NetSuite Account that developing is happening in?

Eric:

I name them like env/production, env/sb1, etc.

I have one group of branches for my development lifecycle:

  • main
  • release/*
  • feature/*
  • hotfix/*

Then I have one group of branches for my environments:

  • env/production
  • env/sb1
  • env/sb2
  • (etc)

Some teams prefer to name them like env/dev, env/uat (with the role of the account instead of the name). I don't like that personally, but that doesn't matter because it's their team - not mine.

(END)


Want to be part of conversations just like this one? Join us in the Sustainable SuiteScript Slack channel.