Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

LC 2022 - Second Generation Packaging

Próximo SlideShare
Application versioning
Application versioning
Cargando en…3

Eche un vistazo a continuación

1 de 41 Anuncio

Más Contenido Relacionado

Similares a LC 2022 - Second Generation Packaging (20)

Más de Keir Bowden (20)


Más reciente (20)

LC 2022 - Second Generation Packaging

  1. 1. Packaging - It's not just for ISVs Keir Bowden @bob_buzzard
  2. 2. CTO at BrightGen 11 time MVP Certified Technical Architect > 10 years package development experience - SI + ISV About Me
  3. 3. Packages 1st and 2nd Generation Ancestry and Branching Choose your Plan Agenda
  4. 4. Packages
  5. 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. 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. 7. 1st and 2nd Generation Packaging
  8. 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. 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. 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. 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. 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. 13. @namespaceAccessible Package COREPKG Package SALESPKG
  14. 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
  15. 15. Ancestry and Branching
  16. 16. V1.0.0 Ancestry - 1st Gen Patch Version V2.0.0 V2.1.0 V2.2.0 V2.1.1
  17. 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,
  18. 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. 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. 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. 21. Choose Your Plan FirstGeneration SecondGeneration Managed Unmanaged Unlocked Managed Org Dependent
  22. 22. 1st Gen Unmanaged Features No namespace Code visible/editable Not upgradeable When to use Never!
  23. 23. 1st Gen Managed Features Namespaced Code obfuscated Upgradeable When to use List on app exchange Features missing in 2GP
  24. 24. 2nd Gen Managed Features Namespaced Code obfuscated Upgradeable When to use List on app exchange Extend 1GP ISV Tightly controlled apps
  25. 25. 2nd Gen Unlocked Features Optional Namespace Code visible/editable Upgradeable Downgradeable Migrate metadata
  26. 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. 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. 28. Migrate Metadata
  29. 29. Migrate Metadata
  30. 30. Migrate Metadata
  31. 31. Migrate Metadata
  32. 32. Migrate Metadata
  33. 33. Migrate Metadata
  34. 34. 2nd Gen Unlocked When to Use System Integrator Enterprise Customer Newer Org Entire Application New Distribute Open Source
  35. 35. 2nd Generation Org Dependent Unlocked Features No Namespace Code visible/editable Upgradeable Downgradeable Migrate metadata Depend on Org Metadata
  36. 36. Org Dependent Org Package
  37. 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. 38. 2nd Generation Org Dependent Unlocked When to Use Mature Org Rely on existing metadata Extend existing apps Enterprise Customer Sweet spot for SI
  39. 39. 2nd Generation Flexibility Managed Unlocked Org-Dependent Developer Collaboration Control
  40. 40. Official Docs Managed : Unlocked : Trailhead : Managed Module : Unlocked Trail : 2nd Gen Launch FAQs - historic interest Developer Controlled : Unlocked : Trailblazer groups : Unlocked : London's Calling 21 Org Dependent Packages More Information - 2nd Generation Only!
  41. 41. Thank You Keir Bowden @bob_buzzard