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?
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
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
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
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
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
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