git Tags for SuiteScript Release Management
Created: February 19, 2025
Recently, I detailed my source control process for SuiteScript projects, but I focused primarily on the branching portion of my strategy. Another useful aspect of source control is tagging, which we can use to provide convenient labels for referencing various snapshots of our repository.
Here's how I go about tagging in my SuiteScript repositories.
Tagging Releases
Every commit (merge) on the main branch represents a Production release and
receives an annotated Tag
identifying it.
# git tag -a <tagname> -m <message>
git tag -a release/20250219 -m "Production deployment 20250219 - Released Airtable Integration"My Release Tags follow the naming scheme release/YYYYMMDD and match
the name and date of the corresponding release/ branch, e.g.
release/20240501.
In the event that multiple Production deployments are made on the same day,
I append an incrementing integer to the end of the date for subsequent Tags e.g.
release/20240501.2, though this should be quite rare.
💬 A commit which "represents a Production release" is not necessarily the same thing as a commit which "represents the current state of Production". The latter is what the
env/productionbranch is for.
It's worth noting that this is the naming scheme I use for account customization projects. If I were developing a SuiteApp or bundle for wide distribution, I would instead use Semantic Versioning for my release and tag names.
The reason I don't use that approach for account customizations is that it is often quite difficult to decide what constitutes a major, minor, or fix change, depending on how much of the account is packed into one repository.
Tagging Environment Syncs
It should be rare that any of the development lifecycle branches need to be synced with the Environment branches. If this is a common occurrence, there is an operations problem, not a source control problem.
Whenever possible, changes made directly to a NetSuite account should be
replicated in a feature/ or fix/ branch and merged through the normal
development lifecycle.
However, this is not always possible or practical.
When a branch must be synced with an Environment, it is done through a Pull Request. I ensure the SDF project in the Environment branch is updated with the current state of the Account, then I create a Pull Request from the appropriate Environment branch to the lifecycle branch to be synced.
Once the Pull Request is deemed safe, I merge it, and tag the merge commit as a Sync.
# git tag -a <tagname> -m <message>
git tag -a sync/production/20250219 -m "Production sync 20250219 - Major permissions update"Sync Tags follow the naming scheme sync/env-name/YYYYMMDD where
env-name is the Account being synced and YYYYMMDD is the date the sync is
being performed, e.g. sync/sb2/20240430.
main is never synced to any Account other than Production.
Retrieving a Tag
Once a tag has been established, I can rapidly retrieve that exact state of my repository with one simple command:
# git checkout <tagname>
> git checkout release/20250219 From there, I can review and operate on this snapshot of my code as if it were the current version. I could run tests on it, deploy it to an account, compare it to other snapshots/commits, and more.
I wouldn't necessarily want to make any changes directly from the snapshot; that would be something I would incorporate into the current version of the code, rather than an old version of it.
Tagging Potential
Tags are extremely lightweight, easy to create, and simple to automate, so you certainly are not limited to these cases. For example, if you have a sophisticated testing or approval process, you may want to tag release candidates, not just actual releases.
Beware, though, you can go overboard. If everything is tagged, nothing is tagged.
In my opinion, tags are most useful on commits you regularly need to reference or audit later. This is usually important on releases but few other commits.
Whatever you decide to tag, do so consistently - even automating it if possible - and it will serve you well.