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
functionality Independent release cadence Communication through well-defined interfaces Identifiable Components from packages are marked with an icon Why Packages?
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
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
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
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
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
Can add or remove at any time - may break code Cannot mix with @AuraEnabled Creates dependency SALESPKG requires COREPKG to be installed @namespaceAccessible Annotation
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
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
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
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