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:
- Open terminal
- Type [git clone]
- Clone the repository
- Change directory
- Run a few SSD (solid-state drive) commands to login
- Create scratch org (for those not familiar with Salesforce, this is like a tiny sandbox with no configuration data)
- Push source code over
- Run tests
- 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.
Want to hear more?
Move the needle with Salto
Do CI/CD more effectively with Salto
Salto is a tool for extracting your business systems’ metadata (including from Salesforce CPQ) and translating it into a human-readable code, which we call NaCl. With Salto, the code from your business apps—such as XML in Salesforce—becomes NaCl, which is much more accessible and intuitive for non-coders. (Case in point: You can show it to a sales manager and ask, “Is that what you mean?” and they’ll be able to understand.)
Using Salto’s API, you can use the CI/CD tool of your choosing to more effectively and efficiently deploy metadata changes in your business systems using NaCl. You can easily set up CI/CD workflows to help you automatically validate, test, deploy, and replicate actions—saving your team time and improving the quality of your updates.
Our latest feature makes it easy for you to deploy or validate from a Git branch. The deployment plan is based on the configuration changes committed to the branch, and supported operation types include:
- Plan calculation: Calculate the deployment plan, along with errors and warnings (CI)
- Validate and test: Validate deployment against the service (currently supported only in Salesforce, with plans to roll out to NetSuite soon) (CI)
- Deploy: Make changes in the upstream service with/without tests (CD)
Conclusion: Why CI/CD is so critical for admins
At Salto, we’ve long been advocates of DevOps practices for business applications. When it comes to CI/CD, the benefits are too numerous to ignore. Adopting CI/CD into your workflows allows you to:
- Detect issues early, when they’re small and fixable
- Automate work that would otherwise have to be done manually—allowing you to save time and move faster
- Spend your time solving more interesting problems
- Deploy much higher quality configuration changes
While CI/CD has long been a part of the software development lifecycle, it’s only starting to gain a foothold in the BizApps space—partly because these practices can feel inaccessible to non-coders. But by using Salto, you can easily incorporate CI/CD practices in a language that everyone can understand, meaning you can collaborate better, work more efficiently, and deploy frequent changes.
So when you and your team embark on big configuration changes, you release them a little bit at a time, automatically testing as you go to ensure they all mesh together perfectly. Then, when it’s time to deploy, there’s no stress—just smooth, seamless updates. Ah, isn’t that much better?