About Salto: Salto's platform helps you and your team deploy, track, and manage your NetSuite customizations effortlessly. Learn more here.

‍

This is the first in a series of articles covering Continuous Integration and Deployment for SuiteScript developers. You can also find this series in SuiteHub.

Continuous Integration, Deployment, and Delivery are tools that provide developers with the means to automate portions of their development lifecycle. They are common practices in the larger software development world but seem far less common in the NetSuite space. As SuiteScript developers, we spend all our time and effort automating processes on behalf of our users or clients, why not automate some of our own tasks?

‍

What is Continuous Integration?

A quick note: Continuous Integration has nothing to do with integrating data between applications - say, SalesForce and NetSuite; it’s not that kind of integration. The “integration” we’re talking about here is the integration of new code - potentially from multiple developers - into a stable codebase.

According to me:

Continuous Integration is a process by which multiple lines of the same code base - usually branches or forks within a source control repository - are merged (or *integrated*) together automatically according to a set of rules defined by the development team. Typically this takes the form of a server application that monitors events within the source control repository, and triggers a series of tasks in response to those events.

According to Atlassian:

Continuous integration (CI) is the practice of automating the integration of code changes from multiple contributors into a single software project.

And according to Digital Ocean:

Continuous integration is a practice that encourages developers to integrate their code into a main branch of a shared repository early and often.  Instead of building out features in isolation and integrating them at the end of a development cycle, code is integrated with the shared repository by each developer multiple times throughout the day.

These are all OK definitions, but they don’t really tell us what we can do or why it matters. Because there are so many tool options and so many things you might use a CI/CD pipeline for, it’s hard to give a complete or concise definition. Before I can even attempt that, though, I feel we have to talk first about who CI/CD might (not) be good for.

‍

‍

Who is Continuous Integration (probably) not good for?

First, CI/CD relies on the underlying code being under source control; if you are not using a version control system for your SuiteScript (git, mercurial, etc), you won’t be able to take advantage of Continuous Integration.

Elsewhere, I have written many thoughts on why you should be using source control for SuiteScript.

Second, if you’re not using the SuiteCloud Development Framework (SDF) (I teach it here) to validate and deploy your SuiteScript projects, incorporating that into your process may be a higher priority than learning and adopting Continuous Integration.

Solo developers, or small teams with small code bases to support, or teams with simplistic operations may not gain much from adding CI/CD to their process. Here, “simplistic operations” is not meant as a slight or insult; it only means you’re not doing much beyond writing and deploying code. If you’re not branching code, performing code reviews, linting your code, or running automated tests over your code, a CI/CD pipeline won’t have much work to do on your behalf.

‍

Who is Continuous Integration (probably) good for?

As your code base and team size expand, however, you will start to see the need for more rigorous process and quality control in your code, and that’s where a CI/CD pipeline will begin to shine.

Teams making and deploying code changes frequently, or teams responsible for maintaining very large, complex code bases will find CI/CD can help streamline collaboration and delivery. Teams performing more sophisticated development operations like feature branching, automated testing, code reviews and linting, documentation generation, and more will find that CI/CD can perform the majority of those tasks for you automatically so that you can focus on writing and delivering quality code.

Lastly, CI/CD is technically for anyone and everyone who wants to use it. If you want to give it a try but fall into one of my “probably not good for” categories, you should still go for it! I’m absolutely not trying to discourage you as I believe anyone can benefit from using CI/CD, but I also understand that not everyone will be allowed or afforded the time required to learn, implement, and maintain it.

‍

Benefits of Continuous Integration

The primary benefit of a CI/CD pipeline is that it can automate the tasks and validations you do manually between writing and deploying your code. To finally begin making this a little concrete, here are a few examples of Continuous Integration frameworks:

• Github Actions 
• Bitbucket Pipelines 
• Gitlab CI/CD 
• CircleCI 
• Jenkins 

And here a few examples of typical development tasks you might automate with a CI/CD pipeline:

• Run SDF to automatically update, validate, and deploy code to NetSuite when a feature branch is merged.
• Run ESLint to validate and normalize the syntax and style of your code.
• Run JSDoc to generate documentation from the comments and structure of your code.
• Run a SuiteCloud Unit Test suite on your code and prevent code with failing tests from being merged or deployed.
• Automatically update the status of an issue in your issue tracker when a code review is created, completed, or rejected.

‍

Drawbacks of Continuous Integration

Of course it can’t all be fun and games; Continuous Integration is not any sort of panacea or one-size-fits-all tool. Continuous Integration is a deep topic with nearly limitless options. That makes the learning curve steep and can lead to analysis paralysis, particularly when you’re just trying to get started.

Adding a CI/CD pipeline introduces more code to maintain and more knowledge the team must maintain. A whole new set of standards, best practices, patterns, and anti-patterns awaits the team looking to adopt CI/CD. It may be difficult for many teams to invest the time required in adopting and onboarding everyone to this new skillset.

‍

‍

What’s Next

The examples given here barely scratch the surface of what’s possible with CI/CD. I encourage you to check out the documentation for these frameworks and look at their examples for inspiration on what’s possible.

In even better news, I’m not the only one writing about CI/CD for SuiteScript. Check out these great CI/CD articles from other SuiteScript developers:

• How NetSuite Powers DevOps Pipelines with SuiteCloud Platform Developer Tools by Erik Klein, NetSuite
• Netsuite Continuous Integration by SuiteHearts
• How to Automate your CI/CD Process for your NetSuite SuiteApp by Keir Kettle, Workiro
• Using NPM, Git, and The NetSuite SDF CLI For Your Dev Workflow as well as Using Containers For Your NetSuite Dev Workflow by Brendan Boyd

This is only the first in a series of SuiteHub articles covering CI/CD. In the upcoming entries, we’ll actually begin building a CI/CD pipeline for SuiteScript development using real-world examples. Stay tuned for more articles and courses right here, and on SuiteHub!