Salesforce Continuous Integration—Concepts, components, and challenges

This site is currently dedicated to discussing Salesforce CI/CD (Continous Integration and Continous Delivery), yet ironically, I've never written about what CI actually is, so let's fix that.

Concepts

Let's first discuss some basic concepts of CI, and then we'll see how they apply to Salesforce DevOps

Origin of the term

The first thing to know is that this is not a Salesforce-specific term; it's a general software development concept.

Some time ago, software developers used to work in isolation; each building features in their computers without much knowledge about what their colleagues were building.

Towards the end of the project, there would be an integration phase where everyone's code would be integrated and tested. As you can imagine, this almost never went well, and more often than not, the integration phase was longer than any other phase in the project.

This problem can easily be replicated in Salesforce.

Imagine you are working on a bunch of flows for 2 months while your colleague is working on a data validation framework based on validation rules, required fields, etc.

And let's imagine you are doing this in separate sandboxes. And now, let's imagine that 2 months later, you deploy both frameworks to a UAT sandbox.

The most likely outcome is that many of those flows you built won't work because they'll hit many of the validation rules your colleague created. Now you both need to reverse engineer everything and make sure it all works together. This is the dreaded integration phase that has plagued software teams for many years.

So in the 90s, a prominent programmer called Kent Beck wrote a book called Extreme Programming, and in this book, he coined the term Continuous Integration:

Code is integrated and tested after a few hours—a day of development at most

So basically, he was advocating the idea of not waiting 2 months to integrate and test your changes; instead, you do it every day, multiple times a day if possible.

So this leads us to the next concept.

What is Continous Integration

Now that we understand the problem CI aims to solve, we can define it as follows:

Before we explain how CI actually works, let's explore a high-level example, going back to our scenario earlier.

With CI, you and your colleague wouldn't wait 2 months before deploying the flows and data validation frameworks to UAT. Instead, you'd deploy your changes as you go, as many times as possible, to an intermediate sandbox, and there, you would ensure that your logic still works.

You do this multiple times a day until the features are complete.

So, it's called Continuous Integration because you are integrating your changes continuously, as opposed to at the end of the project.

It's called Continuous Integration because you are integrating your changes continuously, as opposed to at the end of the project.

Continuous Integration Flow

Before I explain the individual components of CI, it's helpful to see a high-level flow; otherwise, you could get lost in the details.

Let's look at this image:

Here's how CI works:

1- You make changes to your sandbox in relation to 1 user story. No more than 1.

2- You commit those changes to a shared Git repository.

3- A special piece of software known as a CI server picks up the change and starts an sfdx deployment against another developer sandbox called Integration.

4- If the deployment succeeds, great! The first part of the continuous integration phase is done:

5- You log in to the sandbox and test that your flow works as expected. If it does, the 2nd part of the continuous integration phase is done:

Why does it have other people's changes in it?

Because your colleague is doing the exact same thing! That is key to CI.

CI only works if everyone is following the same process. If step 4 or 5 fails, you would know that something about your changes doesn't play along with your colleagues' changes, and you need to work together to fix that right now, not before deploying to production.

You can also check out this video where I show a similar flow:

Components

Now that we know what CI looks like, let's explore the individual components in a bit more detail.

Version Control (Git Repository)

For CI to be possible, you have to keep your sfdx project in version control with Git (there is other version control software, but Git is by far the most widely used). Here's an example of what it looks like to have an sfdx project in GitHub

GitHub - pgonzaleznetwork/dreamforce22-org

Contribute to pgonzaleznetwork/dreamforce22-org development by creating an account on GitHub.

GitHubpgonzaleznetwork

This repository was created by downloading all the metadata of my production org into an sfdx project and uploading it to GitHub

And so, this is where things start to get a little confusing.

When you look at tutorials on using Git, it's all about tracking changes in your codebase and pushing changes to GitHub. It's not straightforward how this is connected to CI.

To see how Git fits into CI, let's go back to our previous scenario and see what it would look like with CI.