What’s the difference between CI and CD?

CI/CD pipelines have become a hot topic in the Salesforce ecosystem, with 82% of Salesforce teams working to implement them, according to the 2022 State of Salesforce DevOps report. What’s spoken about less often, though, is a clear definition of both ‘CI’ and ‘CD’ and an explanation of how they differ — don’t worry, we’ve got you covered.

The key reason you won’t often find a clear definition of ‘CI/CD’ is because each term can be defined in different ways. ‘CD’ can be used to refer to either ‘continuous delivery’ or ‘continuous deployment’, and even though ‘CI’ always refers to ‘continuous integration’, this practice varies widely between different teams. This is why it’s so important for teams weighing up the benefits of CI/CD pipelines to fully understand what’s meant by each term, so they can establish the right automation for their team.

What's CI?

In every definition of CI/CD, ‘CI’ will stand for ‘continuous integration’. ‘Integration’ is based upon your use of version control and, in a simple feature branch development model, refers to merging new development work from a feature branch into the main branch.

It’s critical to do this ‘continuously’ because the longer development work sits in a feature branch, the more likely it is to cause merge conflicts when merged to main. What’s more, if development work is merged to the main branch in huge chunks, rather than incrementally, there’s a large possibility that this final merge will fail. This can be especially frustrating if work from the first day of a six-month project causes the merge of the entire project’s work to fail.

Teams can automate the continuous integration of their work into the main branch. You can configure this for a specified work stage or at timed intervals, which is one reason why each team’s CI process will differ: one team may have development work integrated into their main branch every evening, while another may choose to integrate their work when it’s near completion.

CI often involves automated integration tests. For example, unit tests can be triggered to make sure code still executes as intended and code coverage remains above 75%. Automated builds confirm that your latest changes are deployable to a Salesforce org, work as intended, and play nicely with other customizations in your org. Again, each team will differ in which automated tests they opt for in their CI process.

What's CD?

The definition of CD is split. ‘CD’ can be defined as ‘continuous deployment’, which refers to automating the final release to production so long as any automated tests have passed. This requires complete confidence in your testing process, which is a risk that many teams don’t wish to take.

However, ‘CD’ can also be defined as ‘continuous delivery’, which is focused on delivering value to end users. This embodies the principles of DevOps, by encouraging an efficient release process that remains reliable and successful.

Even though continuous delivery describes an aim rather than a development process, it does encourage a certain type of workflow. Automating the promotion of work along your release pipeline is a great way to accelerate the flow of work and speed of delivery to end users. This may involve continuous deployment, which can get your work live even faster.

How do CI and CD differ?

Putting definitions aside, the focus of CI is moving development work from a silo to the wider development team. By contrast, CD is focused on moving development work to the end user. In combination, they create a CI/CD pipeline — a highly automated workflow that keeps work moving quickly through every stage of your release process.

Though CI and CD do refer to different stages in your release process, both allow you to see value faster. CI allows you to combine your changes with others’ work sooner, reducing the drift that can happen between environments and reducing the potential for lengthy merge issues as you bring your releases together. On the other hand, CD will deliver valuable change to your users sooner, even in user testing environments, for example — this creates a much smaller feedback loop, allowing you to test and adapt your changes quickly so you can nail that production release.

Your CI and CD processes are also interdependent, especially for Salesforce development. Though work may have passed your automated integration testing, you will also need to ensure it is buildable in Salesforce and validates successfully before you can deploy to production. This is why it’s important to view CI and CD together as a holistic development process, with each element supporting the other and your overarching goals with DevOps.

It doesn't have to be complicated

If the complexity of these definitions is anything to go by, it’s clear that the main challenge for teams hoping to introduce CI/CD is upskilling. If you want to learn more about CI/CD and how to use it for your Salesforce releases, check out Gearset’s free ebook CI/CD for Salesforce. It’ll get you over the first hurdle of understanding CI/CD and help you lay the foundations for a successful development process. And of course you can learn more about all things Salesforce DevOps, including CI/CD, on DevOps Launchpad.