Infrastructure as Code (IaC) is the best practice for building on public cloud platforms like AWS, Google Cloud, and Azure. The idea of IaC is to fully automate the operations necessary to stand up a complete infrastructure and application. The concept is best illustrated by the capabilities IaC brings to both Continuous Integration (CI) and Continuous Delivery (CD):
So why am I starting an article about Salesforce by talking about the amazing CI/CD capabilities of public cloud? If you've come to Salesforce from a public cloud background, this may feel a bit like rubbing salt in a wound. Salesforce has long been on defense about CI/CD: people often compare CI/ID on Salesforce unfavorably to the IaC capabilities of public cloud providers, and are dissatisfied when Salesforce's response is mostly, "Well it's not that bad. Is it?"
I hope to sketch out a positive case for the unique CI/CD capabilities of the Salesforce platform made possible by one of the most revolutionary features for developers: scratch orgs. From an IaC perspective, scratch orgs should be a major differentiator for Salesforce when comparing the platform's DevOps capabilities to other enterprise application platforms. While IaC can help you build complex infrastructures on AWS with the click of a button, you still pay for that infrastructure. If you run many builds, that adds up to a pretty hefty infrastructure bill. By comparison, every Salesforce Enterprise or Unlimited Edition customer is provided with a generous allotment of scratch orgs:
Yes, it's an apples and oranges comparison, but imagine building a complex public cloud app and being able to have up to 100 separate instances of the app running simultaneously and being able to rebuild those environments 200 times each day, all for no additional cost!
Alright, now time for a quick story... I was was one of the first internal users of scratch orgs when they were being built at Salesforce. Before scratch orgs, I spent a lot of time writing scripts that would clean out a pool of persistent Developer Edition (DE) orgs used for our CI builds at the start of each build. It was a frustrating experience that scratch orgs made obsolete. Now I could spin up a new org in seconds from a simple API call! I used scratch orgs for many years but was often confused by the name "scratch org." I always thought of it like a scratch piece of paper you use to jot down an idea.
Then, I had one of those a-ha moments at the Salesforce.org Denver Open Source Sprint in 2018. I was working with the Outbound Funds team on great solution they had built for tracking outgoing money for nonprofits (scholarships, grants, etc). They had built something amazing in a Salesforce DE org and wanted to get it to a point where it could be distributed out of that org. We went to work trying to capture their solution into GitHub and configure it to create scratch orgs using CumulusCI. We encountered an issue with our scratch org and decided it was easier to start over.
I said to the group, without even thinking about it, "Let's start from scratch" and immediately had my a-ha moment that sticks with me five years later: Scratch orgs aren't a scratch pad to jot down an idea, they're about enabling you to quickly and easily start from scratch!
That simple reframing of "scratch org" helped me understand their real power. The whole point of IaC is to eliminate the manual operations cost and risk of human error of creating new production ready environments. In other words, IaC is inherently about being able to start from scratch.
There are indeed differences between public cloud providers and Salesforce. Public cloud occupies the space between Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) while Salesforce occupies the space between PaaS and Software as a Service (SaaS). While you'll never be able to do a Blue/Green deployment to Salesforce, scratch orgs make it possible to set up the shift-left CI benefits of IaC by fully testing commits in feature branches before merging them.
Like IaC, realizing the full power of scratch orgs requires investing in automation. Scratch orgs are ephemeral rather than persistent. They are intended to disappear after a certain amount of time, with 30 days as their maximum lifespan. If your users have to spend hours of manual configuration every time they create a new scratch orgs, scratch orgs will stress them out and repel them back to the false comfort of persistent orgs.
By setting a goal of using scratch orgs everywhere possible, you expose the hidden tech debt of missing environment automation for your product. That missing automation encourages the overuse of persistent orgs which add inefficiency and risk to your process while simultaneously limiting your team's scalability. As your team grows, those persistent orgs and serial processes become bottlenecks with exponentially growing inefficiency.
Starting from scratch with scratch orgs makes it easy to test the complete delivery of a fully usable product experience. With the full delivery of your product automated, you can develop, build, test, release, demo, implement and support with full parallelization, allowing your process to scale almost linearly as your team and product suite grows.