[dreamOlé 2022] Starting with Salesforce DX

Salesforce DX has been released a few years back, but not everyone has embraced it yet. If you’re new to it, come have a look to what DX really is, and what are the benefits of using it in your development workflow. Learn where to start and what are the steps needed to move to Salesforce DX. Still have questions ? Should you use git or not ? Use Scratch Orgs or Sandboxes ? We’ll help you answer answer them in this session.

Transcript

2. Starting with Salesforce DX Fabien Taillon Salesforce MVP - CTO at Texeï @FabienTaillon
3. Fabien Taillon - 7x Salesforce MVP - CTO at Texeï - Paris Developer Group leader - French Touch Dreamin team - Serial speaker - Not so serial blogger @FabienTaillon https://texei.com/blog Who am I ?
4. • What is Salesforce DX ◦ A bit of history ◦ Where it is now • What are the benefits • How do I move to SFDX ? Agenda
5. What is Salesforce DX (a.k.a. SFDX)
6. What is Salesforce DX Plan Code Build Test Release CLI for integration with 3rd party editors Scratch orgs for devs, built off of source Continuous Delivery/ build automation Continuous integration with test automation Sandboxes for performance testing, UAT, staging Packaging to streamline delivery to prod VCS as the source of truth IDEs, Text Editors, Language Services A move to a more modern Development eXperience
7. A bit of history At the heart of it when SFDX started, Scratch Orgs: • source-driven development environment • fully configurable (no more case needed to activate Person Accounts) • first environments to include source tracking • ephemeral (from 1 to 30 days) What is Salesforce DX
8. What is Salesforce DX
9. Not only Scratch Orgs, SFDX became a catch-all term A whole set of new tools • Scratch Orgs • sfdx cli • VS Code Extensions (and deprecation of Eclipse IDE) • Unlocked Packages • Better support for Metadata API • Source Tracking What is Salesforce DX
10. Where it is now A growing set of tools • sfdx cli updated every week • VS Code Extensions updated every week • Source Tracking now available on Sandbox And more coming (announced/pilot/beta) • sf cli (cross-products cli) • Code Builder • DevOps Center What is Salesforce DX
11. Benefits for everyone Improvements being done behind the scene on Metadata API support • Day 1 support for most of the new Metadata • Bugs being fixed (e.g. ContractStatus) • Gaps being addressed release after release Benefits to everyone using Metadata API deployments Progress can be tracked in the Metadata Coverage Report: https://developer.salesforce.com/docs/metadata-coverage What is Salesforce DX
12. What are the benefits
13. Safer deployments · Repeatable deployments ◦ No change set to recreate manually ◦ If deployment worked in Full Sandbox, it will work in Prod (99%) · Less manual actions · Crash once fix it forever · More confident to deploy with good automated tests · Faster “time to market” What are the benefits
14. A more standard way of doing things · A better integration in your company’s IT landscape · Use existing tools instead of Salesforce specific ones · Easier non-Salesforce developer onboarding · Benefits from standard tooling like Git or CI/CD tools: ◦ Code is versioned ◦ All changes are tracked ◦ You know what has changed and need to be deployed ◦ Automated testing makes you sure your changes don’t break anything, and you know it early (not the day you deploy in Production) What are the benefits
15. How do I move to SFDX
16. Most important thing to remember: SFDX isn’t all or nothing How do I move to Salesforce DX
17. Changes can be made step by step: 1. Start moving basic metadata to a repo (code, flexipage, flow…) 2. Use a source-tracked environment (for instance Sandbox - one per developer/app builder please) 3. Let developers/app builders add more metadata to the repo when they are modified 4. Setup “automated” deployments (GitHub Actions, Jenkins…) 5. Add automatic testing (Apex tests, code quality scanner 6. Move to Scratch Orgs (or not) 7. Decompose your Org in Unlocked Packages (or not) → https://dxatscale.io will be your best resource 8. Build your own tooling (VS Code Extensions, sfdx plugin with Salesforce framework…) 9. Iterate, fix, improve what’s not working How do I move to Salesforce DX
18. Scratch Orgs or Sandboxes ? · Both now have source tracking Scratch Orgs are better · Really created from source · Easy to merge branches and created the environment we really want · No more headaches with sandbox preview · No additional/unwanted metadata Sandboxes are better · Easier to start, no need to have a 100% coherent repo with no missing dependencies · Still some unsolved issues with Scratch Orgs (org wide email addresses) How do I move to Salesforce DX
19. Scratch Orgs or Sandboxes ? Our recommendation (but really it’s up-to-you): · Use Scratch Orgs ◦ for a small org with few customizations ◦ for a new projects with unrelated metadata ◦ for new orgs · Use Sandboxes ◦ for a complex, old org ◦ to start quickly on an existing simple org How do I move to Salesforce DX
20. Don’t reinvent the wheel, use the tooling your company already has How do I move to Salesforce DX And more...
21. Most important thing to remember, n°2: If you don’t know where to start, moving to Git is a great 1st step! How do I move to Salesforce DX
22. Resources ◦ Decompose your Orgs and use Unlocked Packages: https://dxatscale.io ◦ Using SFDX with Sandboxes - Paris Developer Group (in French 󰏃): https://www.slideshare.net/ParisSalesforceDeveloperGroup/sc ratch-orgsvous-pensiez-en-avoir-termine-avec-les-sandboxes ◦ Getting Started with Salesforce DX (5 parts) - Salesforce Developer Blog: https://developer.salesforce.com/blogs/2018/02/getting-starte d-salesforce-dx-part-1-5 Starting with Salesforce DX
23. Starting with Salesforce DX
24. Starting with Salesforce DX