An Admin’s Guide to Salesforce DX
Let me introduce myself. My name is Jeff Nelson, and I’m a Technical Architect at 7Summits focusing primarily on Salesforce and its associated services. A cohort of mine, Gloria Ramchandani, had a session accepted for Dreamforce 2019, An Admin’s Guide to Salesforce DX, which I was able to co-present at the conference.
You might ask, “Why would an admin need to bother learning about Salesforce DX? It literally stands for Salesforce Developer Experience.” The answer is simple: empowerment.
Despite its title, Salesforce DX is intended to benefit everyone who has ever needed to change metadata in Salesforce, be it creating objects, fields, flows or even developing a Lightning Component or Apex.
The key takeaway is the shift from an Org-Based to a Source-Based deployment strategy. Have you ever had to do multiple cycles of change set deployment because you kept forgetting to include an important metadata artifact? Using a Source-Based deployment strategy can help reduce or even eliminate that issue.
Source-Based deployments are not entirely novel; they have been used since the advent of the Metadata API. The key feature in Salesforce DX is a suite of tools designed to assist the user with retrieving the appropriate collection of source files after you have made your changes. The primary path to achieve this is to leverage a new concept introduced with SalesforceDX: the Scratch Org. Instead of spinning up a Sandbox Org, making your changes and then deploying to test or production Orgs you would instead create a Scratch Org, make your changes, retrieve the source code of those changes and execute your deployments using the retrieved source. Although not explicitly required, once you’ve extracted the source of your changes you would typically move the output into a source control system.
The session Gloria and I presented at Dreamforce goes through this process in two phases: a simpler path for an admin to make a metadata change (in this case creating a new field) both directly on a scratch org as well as making changes in the retrieved source code. The second phase builds upon these steps by moving the changes into source control (in this case git and a github repository), deploying them to a different scratch org and making further changes from there.
Our slides from the session can be accessed here: