Adopt Package Based Development With Org-Dependent Packaging Keir Bowden, CTO BrightGen @bob_buzzard 

Package Based Development 

Benefits of Package Based Development Modular Development ● Related objects, code, configuration ● Logical grouping of metadata Improved Team Processes ● Teams work independently ● Version control source of truth Improved release process ● Packages have their own release cadence ● Straightforward to automate 

The Problem - Happy Soup Mature Org Edition Salesforce Org Metadata ● All objects, automation, code ● No app boundaries ● Many, many teams ● Hard to untangle “These systems show unmistakable signs of unregulated growth and repeated, expedient repair” Brian Foote and Joseph Yoder, 1997 Big Ball of Mud 

The Solution - Org Dependent Packages AKA Second Generation Version Controlled Team Development CLI Integration Build on top of happy soup Unlocked Code visible/editable Up/Downgradeable Migrate Metadata Org Dependent Logically incomplete Depends on Happy Soup Checked at install time 

Standalone Packages Every other type of package! Test coverage checked at create time Package installs with/without Happy Soup Happy Soup references Package metadata Package is independent of orgs May be installed in many orgs Org “Happy Soup” Package 

Org-Dependent Packages Footer Org “Happy Soup” Package Test coverage not checked Happy Soup references Package metadata Package references Happy Soup metadata Package only installs in Happy Soup Fails if dependencies not met 1) (Reading__c.Author__c) referenceTo value of 'Author__c' does not resolve to a valid sObject type 

Sample Scenario 

Sample Scenario Bookstore System As-Is Books Authors Publishers Search Page To Be Readings Search Page Desire for moden, package based development 

Search Page As-Is To-Be 

Other Metadata Author Book Reading Custom Objects Setup Sample Data Apex Classes Setup Sample Data With Readings 

Now for the Code! 

Developing Packages 

Developer Setup Create Sandbox Create Scratch Org Push Happy Soup OR Reset Source Tracking Push Package Code Develop Package Code 

Developer Setup Happy Soup Repository Package Repository Package Metadata Happy Soup Metadata (Push Once, Do Not Change) Changes Made Here End Up Here! Salesforce Org 

Development Process Footer Create Package Develop Package Create Package Version Install Package Version (Sandbox) Test Package Version (Sandbox) Promote Package Version All Good? Install Package Version (Production) Test Package Version (Production) All Good? Done Y N Y N 

Lessons Learned You will need the CLI Plan sufficient time ● Develop -> Package -> Test -> Debug cycle Develop package and happy soup in isolation Avoid editing installed package metadata Watch your package source .forceignore is your friend 

What Next? Demo Repositories Trailhead Modules/Trails Docs Community Content 

Thank you