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

My SuiteScript Source Control Process

Created: February 9, 2021

Last Friday, I launched a free email course: Planning your Source Control Strategy for SuiteScript. It is not a tutorial; it does not attempt to teach you source control commands or tactics. Rather, it aims to help you identify the types of problems and ask the right questions which source control can help your team solve so that you are better equipped to plan and implement your own source control strategy.

You won't find quick answers there; you'll find a lot of research to do and a lot of questions left open for you and your team to answer with what best suits you. If you were only looking for quick answers, or if you're just curious, here's my barebones source control process for SuiteScript work:

  • I use GitLab for hosting.
  • For every Client, I create a Group.
  • For every Project, I create a Repository within the Client's Group
  • Locally, I create a new SDF project and initialize an empty repository
  • I add the GitLab repo as the default remote for the SDF project
  • My default branch name is main; any commit on main is assumed to be Production-ready code.

Some context: For large, long-running projects, I plan regular releases (at least one per month). For short/small projects, I skip the release branch.

  • For each release, I begin by creating a release branch from main.
  • For each task within the release, I create a feature branch from the corresponding release branch.
  • I do my development work in the feature branch, committing and pushing all work at least once per day.
  • When development is complete on a feature, I submit a Merge Request to the release branch.
  • When code review and initial testing are complete, I merge the Merge Request.
  • Repeat as necessary for each feature or fix contained in the release.
  • Once all features/fixes are merged into the release branch, I have a release candidate for user testing.
  • Any changes from testing go directly on the release branch.
  • Once user testing is complete, I merge to main and deploy to Production.
  • I tag the new commit on main with a new version number.

In the future, I'll expand this into more detail, adapt it for different contexts, and potentially publish it in multiple formats. Hopefully it's useful for you to start planning and discussing with your team.

HTH

-EG