Best Practices

How to Do CI with Salesforce

What is the best developer flow for Salesforce development?

Harry Williams

Published:

October 7, 2019

Last Modified:

May 26, 2023

Table of Contents

FREE TOOL

Profiles & Permissions Deployer

Easily compare and deploy Profiles, Permission Sets, and Field-Level Security (FLS) between any two Salesforce organizations.

Get Started

Made with love by the Blue Canvas team ❤️

We often get asked about the ideal continuous integration flow for Salesforce. It can be a tricky topic because there are so many stakeholders who have access to make changes in Salesforce and the tooling has been historically lacking. After working with hundreds of Salesforce developers over the past 9 months, we’ve learned a lot about how different teams are approaching CI. Here is what we’ve uncovered as the best practices for CI with Salesforce. A lot of it is inspired by the incredible Atlassian Dev Flow for Salesforce.

EVERY DEVELOPER AND ADMIN GETS THEIR OWN SANDBOX

Every Salesforce developer and admin should have their own sandbox that they can use to develop and test changes on. This is quickly becoming more common but it is not yet universal. Many teams don’t give sandboxes to their admins yet. Configuration and declarative changes are such a big part of the Salesforce value prop and development flow that it’s essential to properly include declarative changes in the development flow.

USE AT LEAST ONE STAGING OR INTEGRATION ENVIRONMENT

In addition to sandboxes for every developer and admin, you will want to have an additional sandbox (or several) for integrating changes. This is where a staging or UAT environment is useful. It is on this environment that you can merge code and resolve any conflicts in a safe way. You can also use this environment for testing before production. Many teams choose to use a Full Copy or at least a Partial Copy sandbox here.

REFRESH METADATA FROM PROD DAILY

The whole point of using sandboxes is to have a safe place to test code and configuration changes before pushing to production. To make this useful though, your sandboxes need to be copies of your production environment - otherwise your testing will be error-prone. To keep your environments in sync you should refresh the metadata in your sandboxes from production every day. In an ideal CI flow you can accomplish this by doing a pull in Git. Keeping your sandboxes closely mirrored to production will save innumerable headaches down the line.

The org has traditionally been the source of truth. Salesforce DX is aiming to change this by moving the source of truth to external source control systems like Git, but as long as Salesforce allows declarative and configuration changes, the org will remain the ultimate source of truth.

FINDING A SALESFORCE SOURCE OF TRUTH THAT WORKS

Continuous Integration starts with source control and an established source of truth. This has historically been a problem in the Salesforce ecosystem because the org has traditionally been the source of truth. Salesforce DX is aiming to change this by moving the source of truth to external source control systems like Git, but as long as Salesforce allows declarative and configuration changes, the org will remain the ultimate source of truth.

Fortunately, there is a way to reconcile this inherent conflict. Set up a Git branch that mirrors the activity on your orgs. That way if any changes happen on your org, they are automatically committed into your Git history. And if any changes are made to your Git branch they are automatically deployed to the connected org. This way there is no danger of a change in the sandbox not getting committed to source control and throwing things off or vice versa.

Blue Canvas does this for you automatically. You can set this arrangement up in 4 clicks.

With this setup you can code or develop using any Salesforce IDE that you feel comfortable with: MavensMate, Eclipse, Illuminated Cloud, the Salesforce developer console, etc. No matter how changes end up on on a developer sandbox, Blue Canvas will pick them up and put them into the Git branch for that org.

FEATURE BRANCHING WITH SALESFORCE

Once you’ve resolved the source of truth issue, you are ready to set up a branching flow. The perfect continuous integration flow for Salesforce starts with a feature branch. A feature branch is branch from the main code base which is isolated. You can safely make changes on this branch without disrupting production or the work of any of your colleagues. Here you can experiment freely. You can have multiple feature branches going at once.

When you want to migrate the work on your feature branch to your developer org, simply do a pull request or merge between your feature branch and the connected branch for your developer org. With Blue Canvas this will automatically merge and deploy your new changes to your developer sandbox.

Note that it is not essential to use feature branches, it’s just a best practice. You can just do development work directly on your developer sandbox as long as it’s isolated to you.

CODE REVIEW AND TESTING ON UAT

Once you’ve tested your code on your own developer sandbox you are ready to push to the staging environment. It’s a best practice to get a second set of eyes on your changes with a code review.

To do this, simply create a pull request (or a Deployment Request in Blue Canvas). Blue Canvas will search for merge conflicts and do a Salesforce validation. You can have a colleague review your code while this is happening - it only takes a few minutes or seconds depending on the size of the deployment. If it looks good, you can deploy your code to UAT or staging automatically or with a click of a button.

Because we have a one-to-one mapping of connected branches to specific Salesforce orgs, you can automatically deploy by merging in Git.

UAT AND STAGING TO PRODUCTION

UAT and staging environments are for testing and integrating code from different developers and admins on your team. If you’ve got a team of multiple developers, it is here that you can address merge conflicts safely and ensure that one user’s code does not overwrite another’s. You can do more code reviewing and testing here.

You can also use git diff or the Blue Canvas Compare tool to see what differences exist between UAT and production.

If everything looks good in UAT, you can simply open up another Deployment Request with Production or master as the target org. Deploying here is super quick. Blue Canvas will automatically run your unit tests here for you. If everything passes you can deploy automatically or by clicking a button.

POST-DEPLOY STEP

As we mentioned in our three core principles, you now want to make sure that your sandboxes mirror production as closely as possible. Thus after every deploy to production you will want to pull metadata from production down into your UAT environment and all developer sandboxes. With Blue Canvas you can just open another Deployment request and merge the code down stream from master into your developer branches and staging branches without worrying about deleting undeployed work on your sandboxes.

REPEAT

That’s it. Continuous integration is fairly simple but very powerful. Once you adopt this Git flow you will be able to continuously, safely and quickly ship new features and get your development team to be far more empowered to write great code and cool features.

‍

Try bluecanvas now!

Start your free trial!

Get Started

Made with love by the Blue Canvas team ❤️

Blue Canvas Blog CTA

Try Bluecanvas now!

Start your free trial

TABLE OF CONTENTS