Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Salesforce DX 201 - Advanced Implementation for ISVs

1,367 views

Published on

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.

Published in: Technology
  • Be the first to comment

Salesforce DX 201 - Advanced Implementation for ISVs

  1. 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. 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. 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. 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. 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. 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. 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. 8. Important Resources for ISV Partners ISV Technical Enablement for Salesforce DX p.force.com/DX
  9. 9. The Challenge Many ISVs Face When Adopting Salesforce DX
  10. 10. Developer Tooling BEFORE Salesforce DX
  11. 11. Introducing Salesforce DX!
  12. 12. How About This Instead?
  13. 13. Three Reasons ISVs Should Start Adopting Salesforce DX Today
  14. 14. Salesforce DX is Better at Organizing Metadata Source Easier to fix the “Happy Soup” problem
  15. 15. Well-Organized Source is a Prerequisite for Packaging 2 Second-generation Packaging (2GP) requires clear segmentation of code
  16. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 29. A Deeper Look at Organizing Your SFDX Source
  30. 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. 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. 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. 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. 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. 35. Demo
  36. 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. 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. 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

×