.png)
How to use Salesforce sandboxes to set up a Continuous Integration workflow, plus how Salesforce DX affects sandbox management.
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.
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.
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.
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.
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.
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:
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 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.
