** Disclaimer – If you buy Blue Canvas I will not get any commission. This is just an educational blog post.
If you read this blog, you’re probably a fan of automation. It’s in the title after all. You know that automation saves time and headache down the line. So what is the slowest, most painful and manual part of the Salesforce development process for most teams?
For many, it’s deployment and delivery of code and configuration changes between environments. Many wonders: is it possible to make this more automated and cut down on this manual burden?
Fortunately, there is a way. It’s called Continuous Integration/Continuous Delivery or CI/CD for short. In this post, we’ll try to address the following questions:
-
- What is CI/CD?
- What are the benefits for Salesforce teams?
- Why is it hard for Salesforce teams?
- What is Salesforce DX?
- How can I achieve CI for Salesforce?
What is CI/CD?
Continuous Integration or Continuous Delivery (henceforth just CI) is the idea of automating deployments so that that you can continuously integrate and deliver small changes rather than doing massive releases. Typically, when people refer to CI they mean setting up an automated process that allows each developer or admin to be pushing their changes in real time without stepping on others’ toes.
Typically this involves using a source control solution (Git, SVN, etc.) and a CI server (e.g. Jenkins, Travis, etc.). Test automation is also a key component of CI. When you want to submit a change, automated tests run so you know whether it’s safe to deploy or not and if they pass you automatically deploy your changes to the target environment.
Now in practice, CI can look quite different depending on the context. Sometimes you deploy to a QA server continuously but have manual checks before production. In some wild and crazy companies, you can go straight to production. But that is a general idea. Read the rest of this entry!
