Version Control

Tools for developing Suiteapps have come a long way and have embraced some of the industry’s good practices. One of the key concepts for successful app development, especially within large teams is the use of version control systems. They allow for the simultaneous editing of source files, automatic changelog generation, code auditing, release milestones, and through the integration of cloud tools automated testing and deployment.

In this article we will explore the syntax and configurations to execute Continuous Integration and Continuous Deployment for SDF projects. We will use BitBucket and GitHub as examples but feel free to explore other possibilities that could better suit your needs. Basic Git knowledge is assumed for this article.

Continuous Integration and Continuous Deployment

SuiteCloud development happens locally but once a version of your SuiteApp is ready, it needs to be tested and deployed. Continuous Integration and Continuous Deployment deals with automating that process when a commit is created on the main branch.

Bitbucket Pipelines

BitBucket pipelines is a service that allows to automatically build and deploy your code based on a configuration YAML file in the repository. The system creates a fresh container where commands can be run.

The pipeline configuration is a YAML file called bitbucket-pipelines.yml that needs to live in the root of the project. This file has a specific structure that defines what the pipeline does and its parameters. This is an example of a YAML pipeline file:

image: vickcam/suitecloud-cli-node:1.0
pipelines:
    branches:
        main:
            - step:
                name: Deploying to QA
                caches:
                    - node
                script:
                       # Credentials
                                - suitecloud account:ci --savetoken --account $ACCOUNT_ID --authid $AUTH_ID --tokenid $TOKEN_ID --tokensecret $TOKEN_SECRET                   
                    # validation
                    – suitecloud project:validate
                    # Deployment
                    - suitecloud project:deploy

• image. The image tag specifies which container will be used to run the pipeline, Suitecloud needs a specific version of JDK and Node, this image has them installed vickcam/suitecloud-cli-node:1.0
• pipelines. This tag needs to be present as the first in the tree
• branches. This tag indicates that the pipeline will only apply to certain branches within the Git structure, in our example we will apply them only to the Main branch. Underneath the branches tag you must specify which branches you want the pipeline to apply
• - step. This tag indicates a step within the pipeline. You can add as many steps as you need for the process
• caches. Indicates dependencies of external libraries. In this case we need node to be up and running in order to execute Suitecloud instructions
• script. Finally, the script tag contains a list of commands that are executed in sequence. Instructions can be defined inside the YAML file or, if they’re too complex, an external script file can be imported

The main difference between the “- step” tag and the steps within the “script” tag is that new steps can have different caches, run within different images or have specific configurations, while the instructions within the script tag run successively once the environment has been configured.

The YAML pipeline example demonstrated before has already some configurations within it to deploy a Suiteapp. You can see that there are some authentication parameters that need to be included for BitBucket to be able to push the new version of your Suiteapp into your test-drive account. Your credentials should never be included in the script file as plain text, this file lives in the remote repository and it cannot be trusted as secure. BitBucket offers a simple way for secrets to be processed within pipelines.

GitHub Actions

Actions in GitHub are the parallel to pipelines in BitBucket. Their configuration is similar with a few key differences we’ll examine here, but the main process is the same: once a commit is pushed in a specific branch, the action is executed over the files in the commit.

GitHub actions also use a YAML file for configuration, the file can have any name but needs to stored in the .github/workflows folder in the root of the project. An example would be:

name: Deploying to QA
on:
  push:
    branches:
      - main
jobs:
  build:
    name: Build and deploy
    runs-on: 
container:
  image: vickcam/suitecloud-cli-node:1.0
    steps:
      - run: suitecloud account:ci --savetoken --account $  --authid $ --tokenid $ --tokensecret $
      - run: suitecloud project:validate
      - run: suitecloud project:deploy

Of course there are many similarities between the two platforms, the SuiteCloud CLI commands are the same and they both use the same Docker container.

Variables and Secrets

You may have noticed that both files require the use of variables with sensitive data. Raw text for those credentials should never be included in the files, so environment variables are used. You can access the variables from the YAML file by referring to them in the following way: 

BitBucket: $VARIABLE_NAME
GitHub: $

where VARIABLE_NAME is the name of the variable. You can add, edit, or remove variables at the account, repository, and deployment environment levels.

Running the Pipeline or Action

Once all the configuration files and secrets have been entered, the only missing step is to commit a change to the main branch. Because of how it is configured it will run automatically once a change has been pushed to the remote repository.

The UI in the webpage of the service shows the execution progress.

The name is the commit message. After a successful execution, you should be able to log into your Netsuite account and see the Suiteapp deployed.

Moving forward

Implementing version control systems in the development workflow is not easy and adding a Continuous Delivery step makes it harder. But the benefit is clearly apparent, once everything is set up, changes in the codebase are easily tracked, versions of the app are automatically deployed, and everything is thoroughly -and automatically- documented.

These processes can be expanded to add testing, FTP access or many other actions and configurations. CI/CD is a powerful tool that will definitely make your SDF development more robust and reliable.