In my previous blog post, I promised to give some more information on how we’ve set up Bitbucket Pipelines to automate the CI/CD process for our SDF SuiteApp project.
When we started out we followed the guidance around using the CLI or a IDE plugin for deploying to a specific account.
But soon, we wanted to include environment specific configuration - e.g. when we pushed our SuiteApp to a QA account, we wanted it to point at our QA API. Later, when we were at the point of releasing our SuiteApp, we discovered that deployment was a manual process using the SuiteApp Control Centre.
This all meant that each deployment was an environment-specific multi-step process and thus was prone to errors. Imagine the horror releasing your SuiteApp to the world, only to find out that the configuration is pointing to your QA API!
We use Atlassian’s Bitbucket as our remote code repository and one of the features is the ability to automate CI/CD using “Bitbucket Pipelines”. Github has a similar feature called Github Actions as does Gitlab, called Gitlab CI/CD. While the guidance here is specific to Bitbucket, it shouldn’t be too much trouble to adapt for Github or Gitlab.
The first step is to be able to build your project via the command line. This only applies if you are compiling your code (e.g. from TypeScript), including config, or dependant on any steps run by hand or via a IDE command to prepare your project for deployment usually.
If your project is dependent on multiple steps, it’s a good idea to alias those in your package.json file to a single command - e.g.
You can skip this step if this doesn’t apply to you.
The next step is to Dockerize the SuiteCloud CLI. Once you have an image containing the CLI, you can setup actions to watch your repo and use this image to build and deploy your project.
I’ve prepared the following dockerfile based on Amazon Corretto (but you can use any JDK base image) for running the CLI via docker. It’s fairly straight forward - it installs Node via Yum, then installs the SuiteCloud CLI via NPM.
Now I can run this Docker image in interactive mode using the following command -
Or even better is to alias this command - I’ve set up the following package.json:
This allows me to run the image like so
Now you can test that the image works as expected. Once you are happy with the image - push the image to a remote image repository (like DockerHub) for use later.
The next job is to decide when you’d like to build and deploy the project.
If you’ve adopted a ‘gitflow’ branching model, then any commit to the ‘develop’ branch should represent a completed feature to be included in the next release, and any commit tagged on the main (or master) branch represents a discrete version of the project, in which case I’d suggest something like this:
- Build and deploy any commit to ‘develop’ branch to your QA accounts
- Build and generate a ZIP archive of the project when any commit is tagged on the main (or master) branch (which can be manually uploaded to the SuiteApp Control Centre).
Bitbucket Pipelines uses a .yml file to describe these (see the example below). You can see I’ve stored the credentials in Bitbucket and reference them with ‘$xxx’. I’ve also used a prebuilt step ‘bitbucket-upload-file’ to upload my zip file to a bitbucket for download later - there are similar ‘actions’ available for Github and Gitlab.
I hope this helps!
You can read my previous post about how to set up your own NetSuite SuiteApp here.