First presented on January 18, 2018 as part of the monthly AppExchange Technical Enablement webinar series. This deck introduces the SFDX-Falcon template, a specialized Salesforce DX project structure for ISVs. It also provides guidance on how to prepare for second-generation packaging, how to automate complex SFDX tasks with shell scripts, and how Continuous Integration can be used with Managed Packages.

1. Vivek M. Chawla, Peter Martin, Danny Chang
Salesforce DX 201
Advanced Implementation for ISVs
An end-to-end model for ISV application design and
developer workflow using SFDX, GitHub, CircleCI and
First-Generation Packaging
January, 2018

2. Forward-Looking Statement
Statement under the Private Securities Litigation Reform Act of 1995
This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if
any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by the
forward-looking statements we make. All statements other than statements of historical fact could be deemed forward-looking, including any projections
of product or service availability, subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans of
management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or technology developments
and customer contracts or use of our services.
The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our
service, new products and services, our new business model, our past operating losses, possible fluctuations in our operating results and rate of
growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of any litigation, risks associated with completed and
any possible mergers and acquisitions, the immature market in which we operate, our relatively limited operating history, our ability to expand, retain,
and motivate our employees and manage our growth, new releases of our service and successful customer deployment, our limited history reselling
non-salesforce.com products, and utilization and selling to larger enterprise customers. Further information on potential factors that could affect the
financial results of salesforce.com, inc. is included in our annual report on Form 10-K for the most recent fiscal year and in our quarterly report on Form
10-Q for the most recent fiscal quarter. These documents and others containing important disclosures are available on the SEC Filings section of the
Investor Information section of our Web site.
Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently available and may
not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently
available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.

3. Salesforce DX 201
Advanced Implementation for ISVs
Conceptual Prerequisites
Access to Dev Hub
Using the Salesforce CLI
Scratch Org Basics
CI/CD Core Concepts
First-Gen Packaging
Resources
bit.ly/enable-dev-hub
bit.ly/master-salesforce-cli
bit.ly/scratch-org-basics
bit.ly/ci-concepts
bit.ly/packaging-overview

4. Just getting started with Salesforce DX?
Trailhead
bit.ly/sfdx-trail
DX for ISVs Playlist
bit.ly/sfdx-for-isvs
Packaging 2 Beta
bit.ly/pkg2-beta-group
WATCH these videos... DO this Trail... TRY Packaging 2...
YouTube videos that show how to get started
with Salesforce DX, the Salesforce CLI and
how to adopt key features.
Take the Salesforce DX Trail - four modules
that dive into working with Version Control,
CI/CD, the CLI and tips for getting started.
✮ Extra credit ✮
Get an early start with Packaging 2 and you’ll
be in a great place to adopt once it goes GA!

5. Agenda
Meet the Salesforce DX TE Expert team
The challenge many ISVs face when adopting Salesforce DX
Three reasons ISVs should start adopting Salesforce DX today
Introduce an ISV-centric model for implementing Salesforce DX
Demo
Q&A

6. Vivek M. Chawla
@VivekMChawla
ISV Technical Evangelist ISV Technical Evangelist
Peter Martin
@dev4ce
Danny Chang
@DannySFDC
ISV Technical Evangelist
ISV TE Expert Team for Salesforce DX
ISV Technical Evangelist
Kees Heida
@kees_heida

7. Our 2018 Mission Statement
Help ISV Partners adopt Salesforce DX by providing concrete, prescriptive
examples and frameworks that are specific to ISV use cases while working
closely with Product Teams to ensure that ISVs have an internal voice

8. Important Resources for ISV Partners
ISV Technical Enablement for Salesforce DX
p.force.com/DX

9. The Challenge Many ISVs Face
When Adopting Salesforce DX

10. Developer Tooling BEFORE Salesforce DX

11. Introducing Salesforce DX!

12. How About This Instead?

13. Three Reasons ISVs Should Start
Adopting Salesforce DX Today

14. Salesforce DX is Better at Organizing Metadata Source
Easier to fix the “Happy Soup” problem

15. Well-Organized Source is a Prerequisite for Packaging 2
Second-generation Packaging (2GP) requires clear segmentation of code

16. Write code as if you were developing directly in your packaging org
Namespaced Scratch Orgs Allow Branched Development
ns_prefix
(Packaging)
ns_prefix
(Scratch 4)
ns_prefix
(Scratch 1)
ns_prefix
(Scratch 2)
ns_prefix
(Scratch 3)

17. Adoption Doesn’t Have to be “All or Nothing”
Modular Development
w/Projects, Scratch Orgs,
and Automated Packaging
But if you do want to go all-in, we’ve got you covered
Start Using the
Salesforce CLI and
VSCode
Leverage the Salesforce
CLI for Continuous
Integration and Delivery

18. SFDX-Falcon Playbook
An end-to-end, prescriptive model for ISV application
design and developer workflow using SFDX, Feature
Management, Git, and Continuous Integration

19. End-to-End ISV Development Lifecycle With Salesforce DX
Salesforce CLI
and Scratch Orgs
Git Based
VCS
Pull
Request
Continuous
Integration
Packaging
Org

20. Default Salesforce DX Project Directory Structure
sfdx-project
├─ config
│ └─ project-scratch-def.json
├─ force-app
│ └─ main
│ └─ default
│ ├─ aura
│ ├─ classes
│ └─ objects
├─ README.md
└─ sfdx-project.json
Files and directories created by force:project:create
Default Salesforce DX Package Directory
Target for new or converted SFDX source
Still have the “Happy Soup” problem

21. SFDX-Falcon Project Directory Structure
sfdx-project
├─ <ci-config>
├─ config
├─ data
├─ dev-tools
├─ mdapi-source
├─ sfdx-source
│ ├─ <namespace>
│ ├─ unpackaged
│ └─ untracked
├─ temp
├─ README.md
└─ sfdx-project.json
Salesforce DX project/repository organization strategies for ISVs
Important Reminder:
Salesforce DX can be used with any VCS/Host
And many more...
SFDX Project and VCS Repository Root
The SFDX-Falcon model uses Git + GitHub

22. SFDX-Falcon Project Directory Structure
sfdx-project
├─ <ci-config>
├─ config
├─ data
├─ dev-tools
├─ mdapi-source
├─ sfdx-source
│ ├─ <namespace>
│ ├─ unpackaged
│ └─ untracked
├─ temp
├─ README.md
└─ sfdx-project.json
Salesforce DX project/repository organization strategies for ISVs
Metadata and SFDX Source
mdapi-source contains source from MDAPI
retrieves and force:source:convert
sfdx-source holds all SFDX “package
directories” referenced by sfdx-project.json

23. SFDX-Falcon Project Directory Structure
Salesforce DX project/repository organization strategies for ISVs
sfdx-project
├─ <ci-config>
├─ config
├─ data
├─ dev-tools
├─ mdapi-source
├─ sfdx-source
│ ├─ <namespace>
│ ├─ unpackaged
│ └─ untracked
├─ temp
├─ README.md
└─ sfdx-project.json
Default Salesforce DX Package Directory
The name of this directory should be the
namespace prefix from your managed package
Specify this as your project’s default “package
directory” inside sfdx-project.json.

24. SFDX-Falcon Project Directory Structure
Salesforce DX project/repository organization strategies for ISVs
sfdx-project
├─ <ci-config>
├─ config
├─ data
├─ dev-tools
├─ mdapi-source
├─ sfdx-source
│ ├─ <namespace>
│ ├─ unpackaged
│ └─ untracked
├─ temp
├─ README.md
└─ sfdx-project.json
“Unpackaged” SFDX Source
Development metadata that is NOT intended
to be part of your managed package
Ideal for applying developer-friendly security
settings and for org-based developer tools

25. sfdx-project
├─ <ci-config>
├─ config
├─ data
├─ dev-tools
├─ mdapi-source
├─ sfdx-source
│ ├─ <namespace>
│ ├─ unpackaged
│ └─ untracked
├─ temp
├─ README.md
└─ sfdx-project.json
SFDX-Falcon Project Directory Structure
Salesforce DX project/repository organization strategies for ISVs
“Untracked” SFDX Source
Useful for working on experimental code
Synchronize source without being tracked by VCS

26. sfdx-project
├─ <ci-config>
├─ config
├─ data
├─ dev-tools
├─ mdapi-source
├─ sfdx-source
│ ├─ <namespace>
│ ├─ unpackaged
│ └─ untracked
├─ temp
├─ README.md
└─ sfdx-project.json
SFDX-Falcon Project Directory Structure
Salesforce DX project/repository organization strategies for ISVs
Continuous Integration Configuration
The SFDX-Falcon model uses CircleCI
Important Reminder:
Salesforce DX can be used with any CI Provider
And many more...

27. sfdx-project
├─ <ci-config>
├─ config
├─ data
├─ dev-tools
├─ mdapi-source
├─ sfdx-source
│ ├─ <namespace>
│ ├─ unpackaged
│ └─ untracked
├─ temp
├─ README.md
└─ sfdx-project.json
SFDX-Falcon Project Directory Structure
Salesforce DX project/repository organization strategies for ISVs
Developer Tools
Configurable shell scripts that help automate
common development and deployment tasks
Developer/environment-specific config vars are
untracked and allow for local customization

28. sfdx-project
├─ <ci-config>
├─ config
├─ data
├─ dev-tools
├─ mdapi-source
├─ sfdx-source
│ ├─ <namespace>
│ ├─ unpackaged
│ └─ untracked
├─ temp
├─ README.md
└─ sfdx-project.json
SFDX-Falcon Project Directory Structure
Salesforce DX project/repository organization strategies for ISVs
Data
Files (CSV, SObject tree, etc.) and/or
anonymous Apex for importing data
Temporary Files
Local use only (not tracked by VCS)
Stores output from scripts and CLI commands

29. A Deeper Look at
Organizing Your
SFDX Source

30. Get Ready for Packaging 2 by Organizing Your Source
Salesforce DX makes it easier to implement Force.com enterprise design patterns
SCHEMA
SERVICE LOGIC
FEATURE 1 FEATURE 2 FEATURE 3 FEATURE 4
DOMAIN LOGIC UTILITY LOGIC

31. Managed Package Directory Structure
<namespace>
├─ main
│ ├─ default
│ ├─ domain
│ ├─ schema
│ ├─ service
│ └─ utility
├─ feature-one
│ ├─ aura
│ └─ classes
├─ feature-two
├─ feature-three
└─ feature-four
Invest now to simplify the transition to Packaging 2
FEATURE
1
FEATURE
2
FEATURE
3
FEATURE
4
SERVICE LOGIC
DOMAIN LOGIC UTILITY LOGIC
SCHEMA

32. Managed Package Directory Structure
<namespace>
├─ main
│ ├─ default
│ ├─ domain
│ ├─ schema
│ ├─ service
│ └─ utility
├─ feature-one
│ ├─ aura
│ └─ classes
├─ feature-two
├─ feature-three
└─ feature-four
Invest now to simplify the transition to Packaging 2
Salesforce DX Package Directory
Contains all metadata from your managed package

33. Managed Package Directory Structure
<namespace>
├─ main
│ ├─ default
│ ├─ domain
│ ├─ schema
│ ├─ service
│ └─ utility
├─ feature-one
│ ├─ aura
│ └─ classes
├─ feature-two
├─ feature-three
└─ feature-four
Invest now to simplify the transition to Packaging 2
Main Module (Your Application’s Core)
Will become your app’s “core” package once
second-generation packaging (2GP) arrives
Should be buildable by itself
SERVICE LOGIC
DOMAIN LOGIC UTILITY LOGIC
SCHEMA

34. Managed Package Directory Structure
<namespace>
├─ main
│ ├─ default
│ ├─ domain
│ ├─ schema
│ ├─ service
│ └─ utility
├─ feature-one
│ ├─ aura
│ └─ classes
├─ feature-two
├─ feature-three
└─ feature-four
Invest now to simplify the transition to Packaging 2
Feature Modules
Each feature module becomes a package once
second-generation packaging arrives
Require the presence of main module to compile
(may also depend on other feature modules)
FEATURE
1
FEATURE
2
FEATURE
3
FEATURE
4

35. Demo

36. Putting it All Together: End-to-End Development With SFDX
Salesforce CLI
and Scratch Orgs
Git Based
VCS
Pull
Request
Continuous
Integration
Packaging
Org

37. Recap
The time for ISVs to start adopting Salesforce DX is NOW
SFDX-Falcon is an ISV-centric model for end-to-end development with Salesforce DX
Organizing your metadata and app-logic now gets you ready for Packaging 2
Three things you can do today to get started...

38. Fork the SFDX-Falcon Template to kick-start your project
bit.ly/sfdx-falcon-template
Clone and Test Drive the SFDX-Falcon Demo:
bit.ly/sfdx-falcon-demo
bit.ly/sfdx-falcon-group
Join the Partner-Only Chatter
Group for Help/Feedback
1
2
3