Salesforce DX introduces an entirely new development paradigm for Salesforce; Source Driven development, Scratch Orgs, Unlocked packages – there’s a lot of new concepts, capabilities and tools to consider when designing a modern, collaborative development process.
This post outlines a Developer Workflow that combines the Salesforce CLI and Git version control system as one basic example of how Salesforce DX can be applied in practice. The workflow includes a reference to the type of commands that may be executed at each step, however specific details in respect to parameters etc. should be referenced at the links below.
git Reference Manual
Salesforce CLI Command Reference
Assumptions:
A Source Driven Development methodology is applied; the source of truth is git never a Salesforce org.
Source Format is always SFDX (git and local).
Scratch orgs are intended for single developer use.
Developer Workflow:
Developer1 and Developer2 will work collaboratively on a new Feature1 for ProjectA.
git: A new branch is created for ProjectA.
git: A new branch is created for Feature1.
1. Developer1 (and 2):
1.1 create a new local branch Feature1Dev1 and check out to this branch.
[code language=”bash”]$ git checkout -b Feature1Dev1[/code]
1.2 retrieve the Metadata API components from a Source org and convert to Source format. This could be by package reference or manifest.
[code language=”bash”]
$ sfdx force:mdapi:retrieve ..
$ sfdx force:mdapi:convert ..
[/code]
1.3 add source format files to the git branch (not the metadata source).
[code language=”bash”]
$ git add .
[/code]
1.4 create a Scratch org (optionally with an expiry date; max is 30 days).
[code language=”bash”]
$ sfdx force:org:create ..
[/code]
1.5 push source format to the Scratch org.
[code language=”bash”]
$ sfdx force:source:push ..
[/code]
1.6 transport data to the Scratch org.
[code language=”bash”]
$ sfdx data:soql:query ..
$ sfdx force:data:tree:export ..
$ sfdx force:data:tree:import ..
[/code]
1.7 run configuration scripts e.g. PostInstallScript (or equivalent Apex script) in the Scratch org to configure settings.
[code language=”bash”]
$ sfdx force:apex:execute ..
[/code]
1.8 open the Scratch org to make declarative changes and pull to local folder.
[code language=”bash”]
$ sfdx force:org:open ..
$ sfdx force:source:pull ..
[/code]
1.9 modify code in the VS Code IDE and push to the Scratch org. Note, SFDX tracks changes between the local folder and the Scratch org, i.e a pull command will return only detected changes.
[code language=”bash”]
$ sfdx force:source:push ..
[/code]
1.10 create a Scratch org user for any QA users involved in early system testing.
[code language=”bash”]
$ sfdx force:user:create ..
[/code]
2. Synchronisation point:
2.1 Developer1: pushes local branch Feature1Dev1 to origin.
[code language=”bash”]
$ git add .
$ git commit -m "feature1 commit.."
$ git push origin Feature1Dev1
[/code]
2.2 Developer1: create Pull Request (Feature1Dev1=>Feature1)
2.3 CI: create Scratch org, runs unit tests, runs Lightning Lint (Pull Request specific build behaviour)
2.4 Developer2: review Pull Request (Technical QA) (Feature1Dev1=>Feature1)
2.5 Developer2: merge Pull Request to Feature1 branch
2.6 CI: create Scratch org, runs unit tests, runs Lightning Lint (Commit specific build behaviour)
2.7 Developer2: fetch the Feature1 branch from origin and merge to local Feature1Dev2
[code language=”bash”]
$ git fetch origin
$ git merge origin/Feature1
[/code]
3. Feature1 is ready for testing:
3.1 Developer1: create Pull Request (Feature1=>ProjectA)
3.2 CI: create Scratch org, runs unit tests, runs Lightning Lint
3.3 Technical Lead: review Pull Request (Technical QA) (Feature1=>ProjectA)
3.4 CI: create Scratch org, runs unit tests, converts SFDX Source to Metadata API and pushes to ProjectA Salesforce org for QA (Commit specific build behaviour)