Breaking 5 Myths – Scratch Orgs & Salesforce DX : Jitendra
by: Jitendra
blow post content copied from Jitendra Zaa's Blog
click here to view original post
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
- 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.
- 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
Not really, there are two ways to solve this
A. Use CI/CD pipeline to create scratch Org and generate password. Developers can use CI CD pipeline to request scratch Org
B. Another way, create API only user in production with no data permission, give permission to manage scratch org only. Now give JWT command to login in devhub with server.key. As profile is already restricted, developers can use this method to create scratch org. Use this method only when option A is not feasible.
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.
December 07, 2020 at 06:35AM
Click here for more details...
=============================
The original post is available in Jitendra Zaa's Blog by Jitendra
this post has been published as it is through automation. Automation script brings all the top bloggers post under a single umbrella.
The purpose of this blog, Follow the top Salesforce bloggers and collect all blogs in a single place through automation.
============================
Post a Comment