by Jason Fung 
In this post, I’ll be explaining what CI/CD is as part of the DevOps flow. I will provide a simple code change example on how we can benefit from this.
Before we dive in. Here are some top-level benefits:
- Transparency and Accountability
- Increased code quality
- Collaboration
- Fault detection and isolation
- Time-saving qualities
DevOps – CI/CD
If you Google DevOps, you’ll likely find this diagram:
A few words that spring to mind include:
- Infinite
- Forever
- Continuous
- Steps
- Unnecessary?
Indeed, all are valid; well, maybe not the 5th one. However, one which is used frequently when relating to this diagram is continuous.
Continuous Integration and Continuous Delivery. Commonly abbreviated as CI/CD, are words/letters thrown around when talking about DevOps. But what exactly do they mean?
Continuous Integration
This is a world where code changes can be reviewed. Validations, including unit tests, are automatic. You get feedback notifying whether your changes will deploy correctly or not. This is the essence of CI.
Continuous Delivery
This is a world where your CI pipeline successfully validates your changes. It passes code review and you hit the merge button, magically your changes are deployed to your org without having to log into the sandbox. You then manually select the files you wish to include, upload your changes, log into your the org and accept those changes (yes this is a changeset example). This is what CD is all about.
Continuous Deployment
This blog focuses on the Continuous Delivery part of CD. However, it’s worth understanding this.
Continuous Deployment is an extension to Continuous Delivery. A successful pipeline relies on automated testing replacing manual code reviews.
Monitoring also plays a key role. It helps identify regressions via real-time alerts. An example could be live monitoring of HTTP status codes.
Having both these elements in play. You can set up pipelines to automatically deploy your changes. In comparison to Continuous Delivery, a manual approval step is required before changes are shipped out.
CI/CD
The crux of these operations significantly reduces time and allows for smaller iterations of features to safely, more reliably, deploy into environments without you having to do the leg work.
Why should you bother?
The vanilla, out of the box, deployment tools Salesforce provides lacks the autonomy modern-day deployment tools can offer. This hinders confidence, reliability and the time it takes for a feature to be shipped. In most cases, manual steps scream human error. This is something that can be avoided with automated processes.
Setting this up requires source control. This makes it more transparent. Code changes can be peer-reviewed. This increases code quality, as a fresh pair of eye’s, can help spot mistakes. Tools like GitHub, Bitbucket and Gitlab provide web-based repositories allowing easy collaboration. Coupling these with automated processes can help isolate and detect faults quickly.
The screenshot below shows a snippet of metadata that’s available through the traditional change set deployment route. You can start to imagine how confusing this can get when your feature touches other metadata. You’ll need to keep a separate offline list to remember the configuration steps made. With the Salesforce CLI, it’s possible to pull down code/config changes. Have CI/CD deploy them, significantly reducing the time maintaining this offline list and ticking boxes.
Tools like Gearset or Copado offer a hybrid flavour of changesets and modern-day deployment tools. I have used these myself and find they are fantastic tools. They’re far better than out of the box deployment tools offered by Salesforce. However, they still require manual adjustments and remembering exactly what’s changed.
When it comes to reliability and predictability, computers always come out on top. So why shouldn’t you move to a CI/CD world?
Example
This example utilises Gearsets CI/CD tool.
HelloWorld
Gearset acknowledges a new pull request has been created and automatically validates them.
Validation
Happy Path
New Changes
In this example, we’ve added a constructor allowing the returned string to dynamically append a name. With the power of source control, we can navigate to the latest commit and see the exact changes.
Unhappy path
This is a failed validation. You can drill into specific failures by reviewing the validation within Gearset. Or you can log in to your target org and navigate to Setup > Deployment Status.
Timeline
The majority of source control offerings breakdown commits against a pull request. The ticks and crosses represent whether validations for those changes have passed or not.
I find this very useful as it makes it easier to find changes that lead to validation failures.
Merging
Merging the pull request after successful code review and validation triggers the deployment process to begin. It goes through the validation/unit tests stages again and deploys your changes to the target org.
Final thoughts
Adopting CI/CD is encouraged and when done correctly it can be very powerful. It allows multiple developers to work at the same time due to the source control nature. It consolidates changes to one area making collaboration easier. Coupling these with processes to help deliver changes to correct orgs automatically helps save a lot of developer time. (I’m sure they’d rather be squashing bugs than faffing around with manual deployments).
CI/CD can be tricky to get right. Changes to production are inevitable. Admins will add breaking validation rules that don’t exist in your developer sandbox, making your feature break on deployment. In an ideal world, changes should come from a dedicated throwaway developer sandbox; be validated against a UAT/Staging environment before promoting to production. I acknowledge this may not always be possible as getting buy-in from stakeholders can be difficult.
Some metadata just won’t deploy correctly. Config changes to profiles, digital experience etc., may not map properly and will require manual steps. Knowing and understanding what can be deployed is important.
This blog focuses heavily on the developer’s side of the CI/CD story, but what about admins? Truth is, the tools outlined in this blog will require technical expertise, an understanding of source control, the usage of CLI and general DevOps knowledge. All these are readily available to learn online and I’ll provide a list of resources. It’s worth mentioning DevOps Center, a tool for admins is on the horizon so watch this space!
Getting started with CI/CD:
There are many Salesforce CI/CD tools out there already, check them out!
If you have any questions, remember to get in touch.