Lightning Developer Pro Sandbox for Salesforce

‍

In this edition of CTO Corner we thought we’d return to an old favorite topic: scratch orgs! We received the above email from a customer and we thought this topic deserved an update.

The Promise of Scratch Orgs

You’ve probably heard a lot about scratch orgs, but if our customers are any indication, you’ve probably not spent a lot of time actually using them. Scratch orgs were the coolest aspect of Salesforce DX in our opinion. They offered a chance for Salesforce developers to move towards a more traditional developer flow.

The promise of scratch orgs was that they were light weight orgs that could be used in conjunction with feature branches in a Git flow. Salesforce has a unique, org-based, development model which makes declarative, clicks not code style development possible, but which makes a traditional Git-style flow more difficult. The way most teams leverage Salesforce is to make changes in a test environment or sandbox. Part of this is convenience and part of it is the difficulty of getting Salesforce changes into Git.

So Salesforce wisely understood that to get Salesforce developers into a more traditional dev cycle, they would have to include some kind of sandbox or test environment that could correspond to a feature branches.

Traditional sandboxes were too slow to spin up and had severe restrictions on how often they could be refreshed. So there had to be another way to get an Salesforce org that could be quickly created and could be tied to a Git feature branch.

Scratch orgs were the answer. The promise of scratch orgs was that you could spin up a new “sandbox” in about 60 seconds and make your changes. Scratch orgs were meant to be short-lived ephemeral orgs that could be easily connected to a feature or unit of work and then destroyed when finished. The grand vision for scratch orgs was that Salesforce devs would create them as often as they created features.

Where Scratch Orgs Fell Short

However, scratch orgs presented some challenges from the outset. The biggest thing we’ve noticed is that scratch orgs are impractical for many teams to set up. First of all scratch orgs require some familiarity with the Salesforce CLI which is a non-starter for many teams. Furthermore, scratch orgs had confusing settings and required a fair amount of configuration and set up. This did not lend itself to the typical Salesforce developer or admin team.

Accordingly, our CTO, Alex Brausewetter, considers them fairly limited in scope:

In my opinion, scratch orgs are best for new ISV-style projects. Honestly, I recommend waiting for Lightning Developer Pro Sandboxes (LDPS) to become available. Scratch orgs in their current form aren't all that useful, unless you want to spend a few days fiddling with scratch org definition files and finding a way to replicate your current org in their new format.
‍

Scratch Orgs 2.0: Lightning Developer Pro Sandboxes

Here’s our CTO again:

LDPS on the other hand behave like a traditional sandbox but spin up in 5 minutes, instead of hours or days. On top of that, you can create LDPS snapshots and spin up disposable sandboxes from it. So you get the interactivity of scratch orgs, without having to redo your whole process.

‍

‍

LDPS combine the best aspects of sandboxes (easy to spin up, similar to upstream environments) with the best aspects of scratch orgs (speed). With LDPS you don't have to deal with tricky scratch org definition files. You can effectively maintain your current development practices, while augmenting them with the ability to create more sandboxes for different features.

Using LDPS in Git Flow

LDPS are a win for the Salesforce developer community as they move devs closer to DevOps best practices without having to give up their entire workflow.

When a developer wants to work on a new feature they can simply spin up a LDPS and start making changes. Those changes can then be pushed from that org into a Git branch associated to that org.

If another ticket comes in or you want to move onto a new feature you can simply spin up another LDPS and start work there and commit those changes into a different branch entirely.

This allows you to do more independent feature work in isolated environments without having multiple changes going on in the same flow.