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 pushmain
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.