Curious about Salesforce DX and the new packaging? Perhaps you've heard about these but are not sure how to use the new packaging and the core benefit. Join us to learn why and how we moved our development workflow to Salesforce DX, and why we would never go back.

1. Our move to Salesforce DX and
Unlocked Packages
@FabienTaillon
Fabien Taillon, Salesforce MVP – CTO @

2. Salesforce MVP
CTO @ Texeï
Paris Developer Group co-leader
French Touch Dreamin team
Doing Salesforce developments since 2009
Who am I
Fabien Taillon

3. What is DX
Improve the Developer Experience
Plan
Code
BuildTest
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

4. • Packages are built directly from source
• One metadata belongs to only one 2GP
• Only one owner, another team can’t modify something that is part of your package
• Whole project installed
• Not just last modifications pushed to the happy soup like what can be done with ant/Change Sets
• Each Package has a version number
• ie. Not pushing 2 modified Apex Classes, but upgrading from v1.1 to v1.2
• Deals with deletions
• No more additional destructiveChanges.xml or manual action
• Dependencies between Packages
• Repeatable and predictable
What is Second-Generation Packaging
Hint: it’s great

5. Modularizing your code
Organizing configurations, dependencies and metadata into projects

6. • 1st step: Internal tool for developer:
• No dependency with existing metadata
• Small user base
Splitting our happy soup into modules
Moving to DX at our own path

7. • 1st step: Internal tool for developer:
• No dependency with existing metadata
• Small user base
• 2nd step: App for all employee
• Only a few dependencies on objects (Account, Contact…) and no common field
• Everything in one Package
Splitting our happy soup into modules
Moving to DX at our own path

8. • 1st step: Internal tool for developer:
• No dependency with existing metadata
• Small user base
• 2nd step: App for all employee
• Only a few dependencies on objects (Account, Contact…) and no common field
• Everything in one Package
• 3rd step: Project 2 grew + new DX Projects
• Refactoring with Base Package + 2 dependent Packages (1 per project)
Splitting our happy soup into modules
Moving to DX at our own path

9. Working with Salesforce DX
DX development flow
sfdx force:package:version:create
sfdx force:package:install
sfdx force:package:version:promote
sfdx force:package:install

10. Continuous Integration
Validating each commit
LOCAL
code validation
test classes
push

11. Continuous Integration
Validating each commit
LOCAL
code validation
test classes
push

12. Continuous Integration
Validating each commit
LOCAL
code validation
test classes
push

13. Continuous Deployment
How we did it
Base Package
SCRATCH ORG UAT PREPROD PRODDEV
automatic
Projects Packages
manual
automatic automatic automatic
automatic manualmanual manual
manual

14. Use your own tools
We use

15. Use your own tools
We use But you can use whatever you want!
And more...

16. We currently have:
• DX Dev + Package 2
• DX Dev + Ant
• Sandbox Dev + ant
Why ?
• A few stuff is not there for DX
• ex: Audience in Community à Manual step for every Scratch Org creation
• Team/Contractual stuff
• Another team on the same org has not move to DX yet à Repo can’t be the source of truth for a
few stuff
DX is not all or nothing
We still have a lot of different ways to manage our projects

17. Install dependent Packages
First step before using dependent package
Project 1 Package Project 2 Package
Base Package
depends on
Package installation needed for:
• Package creation
ühandled by Salesforce
• Development
• Manual step during Scratch Org setup
• Continuous Integration
• Need to maintain Base Package Id both in
• sfdx-project.json
• CI script

18. Install dependent Packages
sfdx force:package:install --package 04t3xEi15s0Awe50mE
Dependent Id used in several places
In sfdx-project.json In CI script / Dev Scratch Org setup

19. Install dependent Packages
sfdx force:package:install --package 04t3xEi15s0Awe50mE
Dependent Id used in several places
In sfdx-project.json In CI script / Dev Scratch Org setup

20. Automatically install all Package Dependencies:
à sfdx texei:package:dependencies:install -k “1:MyPackage1Key 2: 3:MyPackage3Key” -w 30
https://github.com/texei/texei-sfdx-plugin
Automatically install dependent Packages
Missing something ? Custom sfdx plugin to the rescue!

21. Trailhead Modules
One awesome Trail on DX, lot’s of awesome Modules
https://trailhead.salesforce.com/en/trails/sfdx_get_started
Salesforce DX Development Model
Quick Start: Salesforce DX
App Development with Salesforce DX
Unlocked Packages for Customers
Quick Start: Unlocked Packages
Continuous Integration Using Salesforce DX
Git and GitHub Basics

22. Resources
Working with Modular Development and Unlocked Packages – Blog serie:
https://developer.salesforce.com/blogs/2018/06/working-with-modular-development-and-
unlocked-packages-part-1.html
Architecting Unlocked Packages in Your Salesforce Org:
https://www.youtube.com/watch?v=MY2_AfjtBp8