What is CI/CD and why does it matter for business systems professionals?

Say you need to make a big change to the configuration of one of your business applications, like Salesforce or NetSuite. You spend weeks, maybe even months working on it. Finally, it’s all ready to go. But little did you know another admin has been working on a different customization, and when you go to merge your updates, you realize they’re completely incompatible.

Welcome to merge hell.

Now you have to go back and re-jig everything to make sure it all works together, wasting everyone’s precious time—time that you could be spending on more valuable projects. Wouldn’t it be nice if you could just have avoided this whole snafu in the first place?

That’s where continuous integration and continuous delivery (CI/CD) comes in.

Created by agile developers in the related field of software engineering, CI/CD is a strategy business systems professionals can take advantage of to automatically test, integrate, and deliver new updates, ensuring that everything works together before it gets deployed. So you can avoid merge hell and save your time, effort, and sanity.

Read on to discover what CI/CD is, how it works, and how you can incorporate it into your workflows.

What is CI/CD and where did it come from?

CI/CD is a series of practices to make small, frequent updates to a codebase (or in our case, a business application like NetSuite) while automatically testing and validating them as you go. It’s a core practice of DevOps—a work philosophy that seeks to break down the barriers between development (aka writing code) and operations (aka deploying and maintaining code).

This marks a huge departure from the way traditional software development teams would ship code. Until the early 2010s, dev teams would typically have scheduled monthly or quarterly releases. These were a huge deal—the chance of something going wrong and some critical system failing was high. Just imagine the chaos if a newspaper saved up all its articles for a quarter, or even a month, and tried to publish them on the same day. Typos would be rampant, layouts would look wonky, and there would be misprints galore. But that’s exactly how many development teams used to work.

In 2009, photo-sharing site Flickr made waves when they gave their presentation, 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr. Remember, everyone thought of deployments as these huge, stressful events—it seemed to beg the question, how could anyone possibly be doing ten in a day?

Flickr’s innovation was to think small. Instead of saving all their changes for one massive update, they released tiny changes a little bit at a time, using automated tools to help merge, test, and deploy their code. With small changes, there was much less chance for something to go wrong and destabilize their entire site. And, on the off chance something did go wrong, it was easy to walk back a small change and fix the issue.

To be clear, Flickr didn’t invent CI/CD—the DevOps movement was already well underway. Still, it’s a good example of what CI/CD sets out to accomplish. With CI/CD, there’s no big event—just continuous, manageable updates that happen in bite-sized pieces.
‍‍

With CI/CD, there’s no big event—just continuous, manageable updates that happen in bite-sized pieces.

How CI/CD works

CI/CD is a process, often represented as a pipeline, that allows collaborators to ship small, frequent updates to a shared codebase.

It works by automatically testing different contributors’ changes for conflicts before automatically merging them (CI), automatically delivering validated updates to higher-level environments, instances, or orgs (CD), and automatically deploying approved changes (CD).

Note: A prerequisite for being able to do CI/CD is version control with a tool like Git. If you’re not already versioning, check out our guide to version control first.
‍‍

1. Continuous integration

‍Continuous integration (CI) is the practice of validating and testing small changes (called “commits”) before merging them to a higher branch of a shared team repository. To ensure these changes are compatible before merging them with a higher branch, such as main, a typical CI flow tracks and listens to pending code changes and automatically runs tests and validations. Breaking business needs into small changes that can be tested and shipped separately helps avoid “merge hell” and catch potential issues early.

‍2. Continuous delivery Continuous delivery (CD) is the automated delivery of approved code changes to higher-level environments. A typical CD flow tracks tested and approved code changes and automatically deploys them to higher-level environments, such as user acceptance testing (UAT), production, and so on. This automation of parts of the integration and delivery pipeline means that if you mark an update ready, the pipeline tool automatically runs diagnostics and identifies errors so you can be sure the update is ready for the next phase of review. When you mark an update ready for deployment, the automated pipeline does the deployment, partial rollout, and test, and if broken, rolls it back. ‍

Is CI/CD a tool?

It’s important to note that CI/CD isn’t a specific tool, rather it’s an approach to software delivery that automates testing and deployment. That said, many teams do use CI, CD, or CI/CD tools to support their work. (The other option is to build your own CI/CD servers, but since so many tools already exist, it’s much easier to just choose from the existing options).

Broadly, these tools fall into two categories:

• Tools that are specific to certain Git providers, such as GitHub Actions, Bitbucket Pipelines, Azure Pipelines, and GitLab CI/CD
• Stand-alone tools you can use with any Git provider, such as CircleCI, Travis CI, Jenkins

What CI/CD looks like for admins

While CI/CD emerged as a strategy for software engineers, the implications for business systems professionals are huge. Using CI/CD allows you to much more easily customize your business apps’ metadata, saving you time, effort, and sanity. To illustrate, let’s look at a typical Salesforce DX workflow before CI/CD and then see how CI/CD can help streamline it.

Without CI/CD, here are all the steps you have to take every time you want to make any configuration changes to your Salesforce instance:
‍

1. Open terminal
2. Type [git clone]
3. Clone the repository
4. Change directory
5. Run a few SSD (solid-state drive) commands to login
6. Create scratch org (for those not familiar with Salesforce, this is like a tiny sandbox with no configuration data)
7. Push source code over
8. Run tests
9. Rinse and repeat
   ‍

As you can imagine, doing this over and over again gets repetitive quickly—but luckily, there’s a smarter way to work using Salesforce DX and a CI/CD tool (like GitHub Actions).

Using a CI/CD tool, you can actually automatically create and populate scratch orgs, automatically create pull requests from changes in your scratch orgs, and set up automated tests on your pull requests.

For instance, using GitHub Actions, you can create automated workflows that are triggered by moving cards on your built-in GitHub Kanban board. You can set it up so that when you move a card from “to do” to “in progress,” it automatically generates a new scratch org for you—no manual input required. You can do this for every stage of the development process, saving you tons of time on repetitive tasks and reducing the chance of introducing errors.