LC 2022 - Second Generation Packaging
0 likes•18 views
The document discusses packaging in Salesforce, comparing first and second generation packages, including their features, terms, and recommended usage scenarios. It highlights the differences in namespace handling, version control, and metadata management, emphasizing the advantages of second generation packaging for modular development and dependency handling. Key concepts such as installation processes, branching, and managed versus unmanaged packages are also explored to clarify their implications for developers.
LC 2022 - Second Generation Packaging
- 1. Packaging - It's not just for ISVs Keir Bowden https://trailblazer.me/id/bob-buzzard @bob_buzzard
- 2. CTO at BrightGen 11 time MVP Certified Technical Architect > 10 years package development experience - SI + ISV About Me
- 3. Packages 1st and 2nd Generation Ancestry and Branching Choose your Plan Agenda
- 4. Packages
- 5. 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
- 6. 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?
- 7. 1st and 2nd Generation Packaging
- 8. 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
- 9. 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
- 10. 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
- 11. 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
- 12. 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
- 13. @namespaceAccessible Package COREPKG Package SALESPKG
- 14. 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
- 16. V1.0.0 Ancestry - 1st Gen Patch Version V2.0.0 V2.1.0 V2.2.0 V2.1.1
- 17. 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" SalesforceDXDeveloper Guide, https://sforce.co/3jUdxZH
- 18. 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 ancestorVersion1.0.0 ancestorVersion2.0.0 ancestorVersion2.1.0 ancestorVersion2.0.0 ancestorVersion3.0.0 No ancestorVersion ancestorVersion4.0.0
- 19. 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
- 20. 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
- 21. Choose Your Plan FirstGeneration SecondGeneration Managed Unmanaged Unlocked Managed Org Dependent
- 22. 1st Gen Unmanaged Features No namespace Code visible/editable Not upgradeable When to use Never!
- 23. 1st Gen Managed Features Namespaced Code obfuscated Upgradeable When to use List on app exchange Features missing in 2GP
- 24. 2nd Gen Managed Features Namespaced Code obfuscated Upgradeable When to use List on app exchange Extend 1GP ISV Tightly controlled apps
- 25. 2nd Gen Unlocked Features Optional Namespace Code visible/editable Upgradeable Downgradeable Migrate metadata
- 26. 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
- 27. 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
- 28. Migrate Metadata
- 29. Migrate Metadata
- 30. Migrate Metadata
- 31. Migrate Metadata
- 32. Migrate Metadata
- 33. Migrate Metadata
- 34. 2nd Gen Unlocked When to Use System Integrator Enterprise Customer Newer Org Entire Application New Distribute Open Source
- 35. 2nd Generation Org Dependent Unlocked Features No Namespace Code visible/editable Upgradeable Downgradeable Migrate metadata Depend on Org Metadata
- 37. 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
- 38. 2nd Generation Org Dependent Unlocked When to Use Mature Org Rely on existing metadata Extend existing apps Enterprise Customer Sweet spot for SI
- 40. 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!