Best Practices

Setting Up Sandboxes for Salesforce CI

How to use Salesforce sandboxes to set up a Continuous Integration workflow, plus how Salesforce DX affects sandbox management.

Harry Williams

October 7, 2019

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 ❤️

Continuous Integration and proper release management were two of the biggest topics at Dreamforce ‘16 and many sessions covered best practices for Salesforce development. One that really stood out was Salesforce MVP Alex Sutherland’s talk Managing Change with a Sensible Sandbox Architecture. Straightforward and actionable, the talk is one of our favorites because it concretely lays out how to set up the most important infrastructure for Salesforce development provided by Salesforce: sandboxes.

Managing Change With A Sensible Sandbox Architecture from Alexander Sutherland

Before we can approach CI in Salesforce with tools like Jenkins, Bamboo and Ant scripts, we need a sensible Sandbox architecture. This post will offer a review of Alex’s talk and some of our own thoughts about setting up Sandboxes for CI on the Force.com platform.

Changes in Production

Alex is introduced by Salesforce Success Architect Ingo Fochler and tells an unfortunately familiar story before Alex gets started:

A very large customer created a validation rule and didn’t test it very well. They were using Email-to-Case. The change broke Email-to-Case and it took them four days to find out. When they did they had 12,000 emails waiting.

Needless to say, making changes directly in production is a risky proposition. Success architects see this all too often; sandboxes can help.

I’ve Heard of Sandboxes and Even Use Them, but Remind of the Details

Sometimes in life there are things that we use every day and get lots of value out of but which we don’t know all the details about: WiFi, general anesthesia, machine language. For many it may be the same with sandboxes. We know what they generally do and how they help us, but we often forget which edition does what and what the limitations are.

All admins should have sandboxes too. We call them developer sandboxes but admins are making configuration changes that are just as likely to affect your production environment as code changes so they should be treated in the same way.

Most Salesforce developers and admins know what a sandbox is: it’s a complete configuration copy of your production environment. Stated another way it’s a practice environment for you to create and test changes in a way that won’t affect your users in production.

There Are Four Tiers of Sandbox

Salesforce offers four different sandbox types: Developer, Developer Pro, Partial Copy and Full Copy. Each of these works in principle in the same way but each has different rules around data storage capacity and refresh frequency.

Why Use Sandboxes for Salesforce Development?

Sandboxes allow you to test your code and configuration changes in a safe environment which is isolated from your end-users. You can run manual and automated tests to ensure that your changes work well before moving them into a production environment.

As Alex points out, another reason sandboxes are great is that they allow you to work on multiple things in parallel. No one works on just one feature or project at a time. No one gets all the requirements they need for one project or feature at once and without changes. With sandboxes you can isolate work into different environments. (This concept is similar to “feature branches” in Atlassian’s Git Flow for Salesforce and will be discussed more later).

Sandboxes are also empowering for innovation. They give developers the freedom to try new things, even risky ideas that might pay off big in the long run but which you wouldn’t want to release to production right away.

Setting Up Your Sandboxes

So we all agree that sandboxes are great, but how should a development organization use them. As Alex notes during this talk there is no reason that anyone with Pro, Enterprise or Unlimited edition should not have at least one sandbox per developer. This is important for isolating work and ensuring that people are not overwriting each other’s code.

He also points out that all admins should have sandboxes too. We call them developer sandboxes but admins are making configuration changes that are just as likely to affect your production environment as code changes so they should be treated in the same way.

The specifics of how you will set up your sandboxes will depend on the size of your development team. Alex walks through a few types of sandbox configurations in his talk based on complexity.

Alex’s first example is of a simple sandbox architecture in which a developer has a Dev Edition sandbox for making changes. When they finish changes they push changes to another Configuration Developer Edition sandbox which then goes to a Partial Copy Sandbox for UAT. Then staging and finally production.

Hat tip to Alex Sutherland of CRM Science.

Alex also offers a more complex setup which might look something like this:

Hat tip to Alex Sutherland of CRM Science.

Your setup is going to depend on your organization and needs. However, some general principles do apply:

Every developer and admin should have their own Developer Edition or Developer Edition Pro sandbox. If your plan permits (and it probably does more than you realize) you should let developers and admins use different sandboxes for different features.
Use a Partial Copy sandbox to perform User Acceptance Testing in an environment similar to production. This UAT environment is a great place to run tests and ensure that new changes will not break existing functionality. You can also optionally have a second or third testing environment for staging and integration. This could be a full copy sandbox to really ensure that you are testing in an environment that mirrors production.
Frequently merge changes into UAT or Staging before production.Developer and admins should push their changes into UAT to ensure that changes will “play nicely” together.
Refresh your sandboxes on the schedules allowed by Salesforce. This is something many people forget to do. It’s important to keep sandbox metadata as close to production as possible. At Blue Canvas, we’ve talked to users who have let their sandboxes get very far away from production which makes deploying safely harder and harder with every release. How can you properly test your new code or configuration changes if your production environment looks a lot different from your sandbox? At the very least refresh your sandboxes before each seasonal Salesforce release. This way you can ensure that you are mirroring production accurately.
Deploy frequently too. Deploying small changes often is the best way to develop because it allows you to incrementally improve your application. If something does go awry you can always rollback to the last release. Whereas, if you do long release cycles it can be hard to roll back or even know what is specifically causing a problem.
Use source control.

Why Don’t More People Do This?

Given the clear benefits of sandboxes and testing things before production, why don’t people do this?

For one, making changes in production is temptingly easy. But most development shops are now aware of the drawbacks to this approach. So it isn’t just laziness.

The primary problem is that it’s just really hard to move code between environments. If you’re happy with how your Developer Edition sandbox looks, it’s surprisingly hard to promote those changes into another environment. It’s a slow and manual process using change sets. If you’re trying to automate things with Ant scripts and the Metadata and Tooling APIs it’s a lot of configuration work and still runs quite slowly.

Syncing challenges occur in both directions. Not only is difficult to move your changes from development into staging, testing and production, it’s also hard to refresh your sandbox so that the metadata on your sandboxes mirrors production. Salesforce drastically limits the frequency with which you can refresh sandboxes (only once every 5 days and 29 days for Partial and Full Copy sandboxes). And doing so is a slow, painful and manual process. You may want your development environments to look like production, but good luck getting it there.

Salesforce DX, Blue Canvas and The Future

Salesforce is aware that there are problems associated with it’s current approach to deployments which render its sandbox offering (which is a really really good one) suboptimal. Salesforce DX is an attempt by Salesforce to start addressing this.

One of the most exciting features of Salesforce DX will be Scratch Orgs. Scratch Orgs are a new type of Org that can be spun up relatively quickly and automatically for CI processes. Scratch Orgs will make “feature branching” even more convenient and appealing for developers.

Salesforce DX is also attempting to fix the deployment problem through updates to the Force.com CLI and various APIs. This will be a welcome change and should make it easier to set up a proper Continuous Integration flow.

Blue Canvas will work directly with Salesforce DX as it comes out to ensure that you can leverage all of the best features of DX in a simple and straightforward way.

Finally, Blue Canvas itself makes deployments between Orgs as simple as a click of a button. Blue Canvas uses Git under the hood to make Salesforce deployments extremely fast. This unlocks the value of using sandboxes in a way that has not yet been seen and makes the dream of true Continuous Integration on Salesforce a reality.

‍

Try bluecanvas now!

Start your 14-day trial!

Get Started

Made with love by the Blue Canvas team ❤️

Try Bluecanvas now!

Start your free 14-day trial

Get Started

TABLE OF CONTENTS