Salesforce architects should be involved in the release strategy of a Salesforce org, and this includes having some oversight on how changes will flow from one environment to another and what version control model will be used. 

Most of this translates to configuring what is known as a CI/CD (Continuous Integration/Continuous Delivery) pipeline. Before we get into the specifics, let’s cover some basic terminology.

‍

‍

What is Continuous Integration (CI)

CI is a software development practice where developers commit changes frequently to a branch on a remote repository. Every time a commit is made, the code gets built and unit tests are executed. The idea is to end up with a simple “pass” or “fail” output. In other words, did your change break any existing functionality (fail), or does it play well with the existing code (pass)?

‍

‍

This helps the developers get feedback as quickly as possible so that they can make any changes necessary to make their code play well with the rest of the implementation. 

‍

What is Continuous Delivery (CD)

Continuous Delivery is the ability to get changes of all types into production safely and quickly, in a sustainable way. The goal is to make deployments predictable by ensuring our sdfx projects are always in a deployable state. 

Continuous delivery rests on three foundations: configuration management, continuous integration, and continuous testing.

‍

‍

What is a Salesforce deployment pipeline

A common term you’ll see often is a CI/CD pipeline. I like to call this a Salesforce deployment pipeline just to make it a bit more specific. 

A Salesforce deployment pipeline is an automated process that runs your salesforce metadata through a series of steps, such as quality checks, unit tests, and deployments. This process fires in response to events in your version control repository (for example, when a commit is made, as we saw in the definition of CI).

‍

‍

Each successful step increases confidence in our implementation, and eventually, we end up with something we feel confident can and should be deployed to production. 

‍

A CI/CD checklist

When implementing CI/CD for your Salesforce team, it's very easy to just jump into configuring git, creating some diagrams, etc. 

But to have a successful Salesforce CI/CD implementation that works for your Salesforce team and not against it, you need to ensure its foundations are solid.

In this article, I'll share my checklist of items I think you should consider before implementing CI/CD for your Salesforce org. 

I will not be sharing what I think you should be doing. Instead, it's all about what questions you should be asking yourself; how you answer those questions will become the foundation for your Salesforce CI/CD strategy. 

‍

1- Choose a sandbox strategy

Things to consider:

• How many sandboxes will you have?
• Should each developer have their own sandbox, or should they use a shared one?
• Is there a hybrid approach where some projects use a shared sandbox while the rest use individual sandboxes?
• How will you seed sandboxes with realistic data?
• What is the process for refreshing your full sandbox? What parts of it can/should be automated?

‍

‍

The sandbox strategy has cascading effects in the entire Salesforce deployment pipeline, so make sure to have a justification for every decision you make here. 

‍

2- Choose which Salesforce metadata to track in git

At the core of CI/CD is having your sfdx project in a remote git repository. Things to consider:

• Should I track all metadata or just code-based metadata (apex, lwc, etc.)
• What about changes made by Salesforce admins not familiar with git? How will I include those changes in version control?
• Should we track complex metadata types such as profiles?
• What about changes made directly in production by super users, such as email templates?

‍

‍

You don't need to track everything in git. Instead, you can start with a basic set of Salesforce metadata to begin practicing your CI/CD workflow and work your way up.

‍

3- Choose a git branching strategy

Your git branching strategy is somewhat closely aligned with your sandbox strategy. There are many git branching strategies to choose from. I recommend asking yourself the following questions:

• Is this git branching strategy easy to reason about? Can we easily explain it to new team members, or do we need complex diagrams to make sense of it?
• Does this branching strategy encourage long-lived branches or short-lived branches? It's always recommended to work with short-lived branches.
• Does the main/master branch represent the source of truth or are we just using git as a backup?
• Should I have one branch per Salesforce sandbox?
• Is there a version of trunk-based development that can work for us?

‍

‍

4- Choose a CI server

The Continuous Integration (CI) server is what kicks off the Salesforce deployment pipeline by listening to events in your remote git repository. 

Typical CI servers are:

• GitHub Actions
• Bitbucket Pipelines
• GitLab CI/CD
• Azure DevOps
• CircleCI
• Jenkins

Here are some questions you should ask yourself:

• Is this CI server easily integrated with our remote git repository? For example, Bitbucket Pipelines work directly off your Bitbucket repo; the same is true for GitHub Actions. Other vendors come in the form of an external application that needs to be configured. 
• Are there good community-driven examples of Salesforce deployment pipelines configured with this CI server? Ideally, you don't want to reinvent the wheel. 
• Does the CI server provide out-of-the-box actions that I can reuse? GitHub Actions has a marketplace of ready-to-use actions that can make your pipeline configuration much more straightforward.

‍

5- Choose what to automate

The idea of a Salesforce deployment pipeline is to be able to automate many actions in your release process, such as deployment, unit tests, static code analysis, etc.

But you don't have to automate everything, nor should you include automations simply because everyone else is doing it.

You should ask yourself:

• Do we want to automate deployments?
• Do we want to deploy the entire branch or just the delta (i.e, the difference between commits)
• Should we always run all tests, or can we give the developer the freedom to choose which tests to run?
• Should we automate static code analysis? If so, for which categories?
• Do we want to deploy to a sandbox automatically or just automate check-only deployments (and then manually deploy once you gain confidence in your deployment)?

‍

6- Choose when to automate

Having decided what to automate, the next step is to determine when these automations should run. Remember that your CI server runs actions in response to events in your remote git repository.

I recommend you think about:

• Should I run any automation every time a push is made to a remote branch? For example, should you run all tests every time a developer pushes a commit to a feature branch? 
• What automations should run when a pull request is made? For example, you could trigger a check-only deployment every time a pull request is made to ensure that the deployment will be successful in the target sandbox.

7- Creating the pipeline configuration (plus a gift from us!)

After you go through the above exercises, the final step is configuring your deployment pipeline configuration file. This is typically done with YAML.

Here's an example of the YAML file I use for my Salesforce projects, complete with comments explaining everything.

‍YAML configuration for Salesforce org-based development

‍

This part can be a little overwhelming as you need knowledge of YAML, bash, Node.JS, and the Salesforce CLI.

To simplify this process, I created NaCi (Not another CI tool), a web-based tool that helps you declaratively create a pipeline configuration file in less than 5 min!

You can access it right now at ci.salto.io

‍

‍

It's so easy to use that I will let you explore it yourself. You'll have an entire Salesforce deployment pipeline ready to go in minutes. 

At the time of this writing, the tool is still in beta and only supports GitHub Actions, but support for more CI servers is in the works.

‍

8- Recognize when to use a DevOps tool

Some scenarios are hard to satisfy using your own CI/CD implementation. Such as

1. Integrating the work of admins into the pipeline
2. Including configuration data (CPQ, etc.) 
3. Working with complex metadata types such as profiles, layouts, and flows (working with them in git can be challenging)
4. Comparing two sandboxes to see how much out of sync they are 

Some of the above can be done with a custom CI/CD solution, but it’s much more complex, and it will eat up developer resources in maintaining complicated scripts and troubleshooting deployment issues.

When things get to a certain scale, it may make sense to use a DevOps platform such as Salto. Salto’s CI/CD solution supports all the challenges described above and can be plugged into any existing CI/CD pipeline you may have in GitHub Actions, BitBucket Pipelines, etc. It can also include any configuration data in your pipeline. Other solutions exist as well. 

The point here is that you should recognize when to use an in-house solution vs. an off-the-shelf one. All the steps in the checklist are 100% relevant regardless of which path you choose. 

And that’s it. Having gone through the above checklist, you can ensure your CI/CD pipeline is well thought out. Did I miss anything? Connect with me and let me know!