Download to read offline
Uploaded byKeir Bowden
LC 2022 - Second Generation Packaging
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.
More Related Content
![[Tech Webinar] Second Generation Packaging for ISVs](https://cdn.slidesharecdn.com/ss_thumbnails/2gpwebinardeck-210106180259-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to LC 2022 - Second Generation Packaging
![Automating ISP Networks Using Ansible and IPAM as a Source of Truth [SoT]](https://cdn.slidesharecdn.com/ss_thumbnails/automatingispnetworksusingansibleandipamasasourceoftruthsot-v25-1-251124105117-d7d4ca24-thumbnail.jpg?width=640&height=640&fit=bounds)
LC 2022 - Second Generation Packaging
- 1. Packaging - It'snot just for ISVs Keir Bowden https://trailblazer.me/id/bob-buzzard @bob_buzzard
- 2. CTO at BrightGen 11time MVP Certified Technical Architect > 10 years package development experience - SI + ISV About Me
- 3. Packages 1st and 2ndGeneration Ancestry and Branching Choose your Plan Agenda
- 4.
- 5. A collection ofmetadata 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 Promotesmodular 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 2ndGeneration Packaging
- 8. Terminology Packaging Org (1st) DeveloperEdition 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) SalesforceDX 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 FirstGen 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 inPackaging 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 developeredition 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.
- 14. Explicitly grant accessto 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
- 15.
- 16. V1.0.0 Ancestry - 1stGen 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 - 2ndGen 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 FeatureBranch OrderApprovals Feature Branch LoyaltyCard
- 21. Choose Your Plan FirstGenerationSecondGeneration Managed Unmanaged Unlocked Managed Org Dependent
- 22. 1st Gen Unmanaged Features Nonamespace Code visible/editable Not upgradeable When to use Never!
- 23. 1st Gen Managed Features Namespaced Codeobfuscated Upgradeable When to use List on app exchange Features missing in 2GP
- 24. 2nd Gen Managed Features Namespaced Codeobfuscated Upgradeable When to use List on app exchange Extend 1GP ISV Tightly controlled apps
- 25. 2nd Gen Unlocked Features OptionalNamespace Code visible/editable Upgradeable Downgradeable Migrate metadata
- 26. Example - revert1.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/outof 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.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34. 2nd Gen Unlocked Whento Use System Integrator Enterprise Customer Newer Org Entire Application New Distribute Open Source
- 35. 2nd Generation OrgDependent Unlocked Features No Namespace Code visible/editable Upgradeable Downgradeable Migrate metadata Depend on Org Metadata
- 36.
- 37. Tests run oninstallation 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 OrgDependent Unlocked When to Use Mature Org Rely on existing metadata Extend existing apps Enterprise Customer Sweet spot for SI
- 39.
- 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!
- 41.