Breaking 5 Myths – Scratch Orgs & Salesforce DX

Breaking 5 Myths - Scratch Orgs

Its been around 3 years that Salesforce has released new tooling set for developers – Salesforce DX. I’ve been working on Salesforce since days of S-Control around 2008 and have seen extreme changes on platform for better.

To be honest, it’s tough to keep yourself up to date on latest changes that Salesforce has been doing , however there are resources like Medium, Trailhead and many other blogs to help you get up to speed.

I’ve seen days and written code on Force.com IDE, Developer Console, many web based IDE and definitely my heart and love at the moment is with VSCode more importantly Scratch Org & unlocked packages.

Purpose of this blog post is to bust some of myths around using Scratch Org in Salesforce DX however before I start, lets agree on below aspects of project development & management

  1. Most of projects in Salesforce follows Agile and one of most important aspect of Agile is Devops. Your team should spend enough time & energy in planning Devops strategy like branch structure, tools, processes etc. In my experience , Devops is more about process rather than tool.
  2. On basis of above point, Source of truth for code & configuration should be your Source Code Management , which in most of cases is Git.

What if your project is not following above 2 principles ? Well, you might already able to relate some of problems like why code is overwritten , no track of which class or fields created by who and why ? Your team spending most of time fixing deployment issue instead of working on actual implementation.

Lets not spend more time and directly jump on some of myths about using scratch org

Myth 1 – Scratch Org is only for packaging & ISV partners

Scratch Org can be used for quick POC or actual implementations. I’ve been using scratch org for each user story which normally takes 1-3 weeks of implementation. Every time, scratch org created, I get liberty to choose which Git branch would be source of truth. Can you refresh dev pro sandbox from Full copy or use 10 days old code that was in production ? There are many other considerations while creating sandbox, you don’t have much control on which metadata would be carried over as starting point.

Myth 2 – No easy way to get metadata from Sandbox to Scratch Org

Ask your self, when was last time you refreshed Sandbox ? Months, May be year ? Then ask another question – Why you are not refreshing your sandbox ? Most probably answer would be , we don’t know what will break or what are post refresh steps. Or original team is not in project and you are not comfortable refreshing sandbox.

Problem is not getting metadata from Sandbox to Scratch Org, real problem is what’s source of truth for your metadata ? If you have SCM as source of truth then its just one command to get metadata in scratch org. In fact you can go any point in time in past to see how code was working to debug some issue in production which is huge advantage.

Myth 3 – Sandbox & Scratch Org cannot be used together

There are multiple way you can use Scratch Org. Example – Each developer using it for stories assigned to them, once story moved to testing , dispose scratch org and create new. If you are using mob or pair programming , multiple developer can have access scratch org at the same time.

How many times you or your team missed components while deploying code ? Out of 20+ components, its easy to miss few. In scratch Org, push & pull commands are life saver. It will auto track changes for you. If your code not working as expected or POC got pushed to next year, start again from SCRATCH & don’t worry about dormant code, metadata in your sandbox.

Myth 4 – As Scratch Org expires in 30 days, its no use for long running projects

First, as per best practice, project should be modularized in small reusable components instead of monolithic code. Any requirement can be easily broken to small modules that can be implemented in 2-3 weeks. If developers are struggling with writing modular code, I would suggest going through some of design patterns mentioned in my book and see how reusable, maintainable and performant code could be written in Salesforce.

Second, even if you are working on monolithic code, if source of truth is SCM then you can create scratch org anytime with draft / intermediate code stored on branch.

Myth 5 – Every developer would need access to Devhub if they want to create scratch Org

True, but you don’t need to pay for license and no need to worry about data security in production.

Salesforce provides free limited access license that can be assigned to all developers who need to create scratch org.

As you have reached towards end of this post, first 5 comments will get free access to Udemy course about what is Salesforce DX & how to use it effectively. Also, let me know if there is something else stopping you from using scratch org in your project.

Related posts

8 thoughts on “Breaking 5 Myths – Scratch Orgs & Salesforce DX”

  1. Thank you so much those topics are very real specially in my experience. Getting a devops strategy implemented also needs commitment from managerial level that sometimes is not ready to provide
    Thank you so much again for your great blog.

  2. Enterprise org has more than 10 pkg on avg, and deploying them with other large set of metadata can take min 1 hr. This stops me on using scratch org. Each pkg again has some settings.
    Another was distributing new scratch org to dev Team. I will try to use ur suggested approach. If there is helpful link on same, plz share.
    I will few more points soon.

Leave a Reply to ankit Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.