SFDX Scratch org creation

[devvrat...@gmail.com]

Hi All,

I have so far worked only with the traditional SF development model where each developer has a Developer Sandbox. I am now trying to learn SFDX model and I am stucked with a very basic understanding of the SalesforceDX architecture. 

In my understanding, to create a sratch org, user needs to login with Devhub org which is enabled on the production org.  Does every developer then needs to authenticate first with production login to create the scratch org and then push the changes to VCS? Is my understanding correct here? I am not getting where to begin, from where I should create the scratch org.  

Also I have seen the plural Sight : play by Play sfdx series recently posted by Scott. Will it be right to say that SFDX model is good for ISVs but not from industry implementation where meta data is so huge to create a scratch org? 

Thanks. Dev

[sc...@illuminatedcloud.com]

Yes, all users who want to be able to create and work with scratch orgs will need some access to the Dev Hub. Here's Salesforce's own documentation on how to manage Salesforce DX users:

https://developer.salesforce.com/docs/atlas.en-us.214.0.sfdx_setup.meta/sfdx_setup/sfdx_setup_add_users.htm

These users will need to auth into the Dev Hub using either shared or dedicated credentials, then they will be able to use that Dev Hub to factory scratch orgs. Once that's done, they'll be able to push and pull metadata between the local filesystem and the scratch orgs, and of course in general the metadata in the local filesystem should be ultimately mastered in a version control system.

As for whether SFDX is useful for non-ISVs, it definitely is. While the migration path to SFDX will be more straightforward for ISVs who have already likely been working in a mode that encourages decoupling of metadata from the org, there is a migration path for Enterprise developers as well. I provided an overview of that migration path in my Pluralsight course, but there's only so much you can cover in 2-3 hours. I described the expected benefits and some potential strategies for extracting and organizing features/products from the "happy soup" so that it can be managed using SFDX tools and processes. For both ISVs and Enterprise developers, there's a non-trivial up-front cost to this switch, but the benefits of it should justify that cost in the end.

I hope that helps. Let me know if you have other questions.

Regards,

Scott Wells