A scratch org is a Salesforce environment that can be easily created to support agile development and continuous integration.
The first thing you learn when you start using scratch orgs is that they die. Quickly. When they first came out, scratch orgs lasted just seven days and even though that time has now been extended to 30 days, it still isn’t long. So, why use them in the first place?
Benefits of Scratch Orgs
Scratch orgs give you some huge advantages over a traditional sandbox development environment.
You can enable features in your scratch org that may not exist in your production environment, without contacting Salesforce support or buying extra licenses. Want to try out multi-currency? Use Person Accounts? Build an Einstein Bot? You can do all those things and more just by adding lines to the configuration file.
2. Source Driven Development
If you’re used to developing in standard developer sandboxes, then you may have experienced a situation where your development environment got really snarled up. Perhaps you were working on a couple of new features; one was ready to go, but you found a serious issue with the second one late in the day and it stopped you from releasing the good stuff. Scratch orgs, used properly, will free you from this.
With Scratch orgs, the single source of truth for everything you’re working on is in your source repository – GitHub or similar. You’re not reliant on any particular org to maintain your source and that’s very liberating. It’s easy to pull and push your changes into and out of git. In turn, this means you can easily manage multiple git branches, developing different features in each one using separate scratch orgs and only merging these back into your sub and main branches when they’re ready.
You get a very high level of granularity and control about where and when you do your testing. You can test a single issue, a feature branch, pre-merge, post-merge; wherever makes the most sense for your particular use case. You certainly don’t have to wait until stuff gets back into QA and that means you can spot problems at an early stage and avoid much bigger problems later on.
The Big Problem
Data, data and data!
Our app has something like 40 custom objects. Sometimes you may not need much data in order to work on whatever it is you’re doing. But sometimes you do. It could be your feature is multiple levels deep in the data structure. You need to create records in parent objects and parents of parents and so on. Just to know a two-minute bug fix has worked, you might need to create 20 or 30 records. It can take longer to create the data than fix the issue.
Which leads to bad habits. It’s super-tempting to use the same scratch org to work on multiple issues so that you don’t have to create that data all over again. Then you can find yourself in the same source code mess that you had with old-style sandboxes, except that this time you know your scratch org won’t be around tomorrow. Testing is also a big challenge. Testers need their own scratch orgs and those won’t have any data to work with either.
The data issue was a real problem for us. As our development team was growing, the consequences were multiplying. There had to be a better way.
Well, there is. But it took some tracking down … there’s a help file article and some sample files that promised everything we were looking for, but they didn’t come with an instruction manual. There was almost no information that I could find anywhere on the web about how to build these files either. We had to work it out for ourselves, but I want to save you the trouble.
Check out my session, recorded at the London Developer Group, where I explain the solution we now use and why you should do this too.
Thanks Todd Halfpenny for the picture 🙂