Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Second Generation Packaging - It's not just for ISVs

Second Generation Packaging - It's not just for ISVs

Slide deck from my talk at London's Calling 2022 on second generation packaging.

Keir Bowden

January 29, 2024
Tweet

More Decks by Keir Bowden

Other Decks in Technology

Transcript

  1. CTO at BrightGen 11 time MVP Certified Technical Architect >

    10 years package development experience - SI + ISV About Me
  2. A collection of metadata components Treated as a single unit

    Install in one atomic operation Everything goes in, or nothing does Remove in one atomic operation After removing local references … Deletes data for packaged objects What is a package
  3. Distribution Internal Selected customers Entire world Promotes modular development Isolated

    functionality Independent release cadence Communication through well-defined interfaces Identifiable Components from packages are marked with an icon Why Packages?
  4. Terminology Packaging Org (1st) Developer Edition for First Generation package

    development Namespace Prefix applied to all metadata Package version Snapshot of the components at a point in time Immutable Subscriber Org Org where package has been installed
  5. Dev Hub (2nd) Salesforce DX Developer Hub Create and manage

    second generation packages Create and manage scratch orgs Unpackaged Metadata Metadata required during package develop/test Not included in final package Beta version Unreleased version of a package May never be released Install only in scratch, developer or sandbox orgs Promote to release if testing successful Terminology
  6. Comparison Source of Truth First Gen Second Gen Packaging Org

    Version Control SFDX/CLI Optional/Basic Mandatory/Integrated Team Development Challenging Straightforward Create Version Packaging Org UI Filesystem + CLI Namespace Single Package Multiple Packages Ancestry Linear Flexible Unpackaged Metadata Mixed in org Declarative
  7. Namespace defined in Packaging Org Unique to each package Restricted

    to this one org Expose code through global keyword Blunt instrument Code available to everyone • Subscriber Org • Any other packages installed in that org Namespace - 1st Gen
  8. Defined in developer edition Registered in Dev Hub Available for

    multiple packages Potential for namespace collisions E.g. BOOKSTORE__Book__c in two packages Expose code through global keyword Namespace - 2nd Gen And @namespaceAccessible annotation
  9. Explicitly grant access to each member Class Method Property Interface

    Can add or remove at any time - may break code Cannot mix with @AuraEnabled Creates dependency SALESPKG requires COREPKG to be installed @namespaceAccessible Annotation
  10. Define previous version (ancestorVersion) Optional Ancestry - 2nd Gen 1.25.0

    can extend 1.24.0 released version And any ancestors of 1.24.0 "Use the ancestor that’s the immediate parent of the version you’re creating" SalesforceDX Developer Guide, https://sforce.co/3jUdxZH
  11. Ancestry - 2nd Gen V1.0.0 V2.0.0 V2.1.0 V2.2.0 V3.0.0 V3.1.0

    V4.0.0 V4.1.0 ancestorVersion 1.0.0 ancestorVersion 2.0.0 ancestorVersion 2.1.0 ancestorVersion 2.0.0 ancestorVersion 3.0.0 No ancestorVersion ancestorVersion 4.0.0
  12. Parallel development streams, like version control Multiple beta versions with

    the same number Only one can be promoted to released Use --branch <name> switch when creating version Branching
  13. Branching 2.0.0 2.0.0. 1 2.1.0. 1 2.1.0. 2 2.1.0. 1

    2.1.0. 2 2.1.0 Version Control Merge Feature Branch AuthorReading Feature Branch OrderApprovals Feature Branch LoyaltyCard
  14. 1st Gen Managed Features Namespaced Code obfuscated Upgradeable When to

    use List on app exchange Features missing in 2GP
  15. 2nd Gen Managed Features Namespaced Code obfuscated Upgradeable When to

    use List on app exchange Extend 1GP ISV Tightly controlled apps
  16. Example - revert 1.33 version of package to 1.25 Downgrade

    Package Metadata is : Modified (Apex classes reverted to 1.25) Deprecated (Custom objects not present in 1.25) Deleted (Report not present in 1.25) Fails if local code depends on 1.33 code
  17. Move metadata in/out of package Release metadata from package into

    org Claim metadata from org in to package Collaboration required Cannot use namespaces Package and org must be logically complete No demo, just screenshots (sorry) Migrate Metadata
  18. 2nd Gen Unlocked When to Use System Integrator Enterprise Customer

    Newer Org Entire Application New Distribute Open Source
  19. 2nd Generation Org Dependent Unlocked Features No Namespace Code visible/editable

    Upgradeable Downgradeable Migrate metadata Depend on Org Metadata
  20. Tests run on installation Faster development Slower installation Complicates development

    process Dependent metadata must be present during development Local changes may prevent upgrade - collaboration required Scratch orgs can be a challenge Tooling can't tell the difference Dependent metadata can sneak into package LIkely to target fewer subscriber orgs Org Dependent
  21. 2nd Generation Org Dependent Unlocked When to Use Mature Org

    Rely on existing metadata Extend existing apps Enterprise Customer Sweet spot for SI
  22. Official Docs Managed : sforce.co/398qygi Unlocked : sforce.co/3NuNBk9 Trailhead :

    Managed Module : sforce.co/3GUTmFr Unlocked Trail : sforce.co/38W51qQ 2nd Gen Launch FAQs - historic interest Developer Controlled : bit.ly/3MsZV2W Unlocked : bit.ly/3O1ZWMO Trailblazer groups : Unlocked : sforce.co/3xo6jEC London's Calling 21 Org Dependent Packages youtu.be/XzUWr6gV9zk More Information - 2nd Generation Only!