Last Updated on November 8, 2020 by Rakesh Gupta

** 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.

What are the benefits of CI for Salesforce developers and admins?

For businesses, CI means less expense and higher customer satisfaction through faster feature releases and fewer bugs.

With CI you can automate deployments so changes happen faster. There is no more “waiting for QA” status. This benefits users because a feature can be live and in production as soon as it’s ready.

The speed enhancements are also beloved by developers and admins. It’s much more exciting to see your code live and get feedback on it than to have it languishing on your sandbox. Furthermore, it allows developers and admins to save time and money by focusing solely on writing features that matter, not spending time doing manual deployment steps with things like Change Sets.

Another benefit to automation is error reduction. Anything that is manual is prone to mistakes and error. A proper CI process for Salesforce reduces bugs because you don’t have manual mistakes. This is especially true with automated tests. Automated tests mean that tests are run every time. Not just sometimes. And edge cases can be more easily tested every time because you just have to write a test once to run it a thousand times.

Why is CI hard for Salesforce historically?

Though CI has risen in popularity in other platforms like Java, Ruby, Python, etc. it has struggled to become mainstream for Salesforce. There are a few reasons for this.

The first is that setting up source control for Salesforce can be difficult. Of course, every Salesforce team should be using source control but it hasn’t always been easy to do that.

For one, admins and declarative developers don’t necessarily want to use the command line. Salesforce has a philosophy of clicks not code. And that is a great thing. But it doesn’t lend itself readily to CI. If you don’t have source control you can’t do CI (more on that later).

The other big factor is that the Ant migration tool and Change Sets are relatively unstable and manual and difficult to fit into a typical CI pipeline.

Salesforce DX

To make CI more achievable, in 2016 Salesforce announced Salesforce DX.

DX is an exciting new set of command line and API based tools. Salesforce DX includes the new and improved Salesforce CLI which allows for easier pushing and pulling from the command line. It also provides for the creation of scratch orgs which are a new type of ephemeral sandbox that you can use to quickly spin up and test on. Scratch orgs can be created in a matter of minutes and persist for 7 to 30 days. DX also includes a new directory format that breaks down large metadata XML files into smaller components for easier management.

On the whole, you can think of DX as a toolkit to make setting up CI in a traditional sense simpler.

How to achieve Salesforce CI?

DX is only part of the story though. DX is a series of tools that you can use, but the responsibility for moving to CI still remains with the Salesforce dev and admin team. And many of the challenges that we listed above with regard to setting up CI for Salesforce persist.

Source Control

The first step to achieving CI is adopting what DX calls “source driven development”. Git is the most popular tool for source control and has gained rapid adoption. You can use generic tools like open source Git, GitHub or Bitbucket, or Salesforce specific source control tools like Blue Canvas.

The best way to set up CI for Salesforce is to automate as much as you can. You want to empower your team to move fast without blocking them. It’s become a best practice to set up automatic Git syncing for your Salesforce environments. Blue Canvas offers this for a monthly fee or you can use DX to set it up yourself with a tool like Jenkins. This solves the admin problem and ensures that your entire team can use source driven development.

Choosing a CI Server

Step two is setting up a CI server. You can use a tool like Jenkins or a Salesforce specific tool like Blue Canvas to get this set up depending on your team and requirements. With this step, you can automatically kick off tests before you merge code between environments and deploy automatically when tests pass. This allows your team to move fast and in an agile fashion.

You’ll need to do research on different CI options for Salesforce to find out what is best for your use case. We recommend checking out Jenkins, Travis CI, CircleCI and Blue Canvas for a Salesforce specific CI tool.

Conclusion

It is possible to do CI for Salesforce and in the last few years, there has been an explosion in interest and tooling to help make this a reality. Finding the right set of tools can be a process of discovery and research. But once you do, you’ll find that your team is happier and shipping higher quality code and configuration changes faster.

Note: – If you have something interesting to say about Salesforce admin or developer. Whether you have a post in mind or would like to collaborate on one, get in touch with me here info@automationchampion.com

About the author

This is a guest post by Alex Brausewetter, founder of Blue Canvas. Blue Canvas builds tools for Salesforce developers and admins looking to implement source control and CI.