Scratch Org Based Development on SFDC - Part 1
Published: 2021-11-04 19:23:23

In this series will follow my own attempt of setting up a Production-ready(ish) environment leveraging the benefits of Salesforce scratch org based development using SFDX. 
The Goal here is to setup a Source Control based development approach for an SFDC Project, leveraging SFDX, CI/CD. Roughly, this is what I had in mind

![Project Git Strategy](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3ajkbqjbilkyhh1ujzwh.png)

## Part 1 - Setting up your Development Environment

###1. Enable Dev Hub in your Main Org
> Enterprise preferred but Dev Edition works as well if you don't have one, note the [limits](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_setup_enable_devhub.htm) for number of scratch orgs and number of active orgs which varies by instance.

* Log in as System Administrator to your Developer Edition, trial, or production org (for customers), or your business org (for ISVs).
* From Setup, enter Dev Hub in the Quick Find box and select Dev Hub.
* If you don't see Dev Hub in the Setup menu, make sure that your org is one of the supported editions.
* To enable Dev Hub, click Enable.
After you enable Dev Hub, you can’t disable it.

###2. Provide access to developers to the DevHub to spin-off Scratch Orgs from it
> If you don't have enough licenses, use the [Free Limited Access Licenses](https://developer.salesforce.com/docs/atlas.en-us.234.0.packagingGuide.meta/packagingGuide/dev_hub_license.htm) for your developers

![DevHub Developer Permission Set](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/i4lym1eitwxw4g45qcr6.png)

* To give full access developers to access the Dev Hub org and spin off scratch orgs via CLI , create a permission set that contains these permissions.

1. Object Settings > Scratch Org Info > Read, Create, Edit and Delete
2. Object Settings > Active Scratch Org > Read, Edit and Delete
3. Object Settings > Namespace Registry > Read (to use a linked namespace in a scratch org)

![DevHub developer Permission Set Object Access](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lia58f1o6tgyxitssa3d.png)

* Now Create a Developer User in your DevHub
4. Create a new user with the Salesforce Limited Access - Free user license and the Limited Access User profile. Add the Permission Set you created for Dev Hub access to the User

![User Setup](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/a7ernb4482dmip3euz21.png)

![Add Permission Set](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/icynei09yq2ppg51cgm4.png)

###3. Setup Project in VSCode
> Ensure you have your VSCode Environment setup for Salesforce Development before you proceed. Follow the instructions [here](https://developer.salesforce.com/tools/vscode/en/getting-started/install) if you donot before proceeding.

1. Authorize the DevHub Org in Salesforce CLI. Give it a unique alias name that is easy to remember for you. I'm using <b>HEDevHub</b> in my case.

![Authorize Dev Hub](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/li8bwkqj6ffxsv9idajj.png)

### Summary
So far we've setup a DevOrg, added a developer user to be able to spin up Scratch orgs from your DevOrg and authorized the DevOrg in your local environment via Salesforce CLI.
Next we want to setup a Continuous Integration Pipeline for our project. There are number of free and opensource as well as paid CI tools for Salesforce. For our use, we will be leveraging [CumulusCI](https://www.apexhours.com/automate-the-app-lifecycle-with-cumulusci/) which is a free, open source tool that builds on Salesforce DX to automate scratch org setup and configuration, seed data into sandboxes and scratch orgs, and deploy apps between environments. 

### References
[Trailhead - Cumulus CI](https://trailhead.salesforce.com/en/content/learn/trails/build-applications-with-cumulusci)