Plan Your Move to Packages
Learning Objectives
- Identify use cases where you can shift to a modular (package development) approach.
- Identify a scenario that doesn't lend itself to package development.
Next Stop: Plan Your Transition to Packages
Now that you understand the value of the packaging development model, you're interested in moving forward with it. So how do you begin? Your next steps depend on the complexity and maturity of your production org and the associated development processes. Here are some suggestions to help you get started.
Why Now Is a Great Time to Adopt Packaging
Unlocked packages provide a repeatable, scriptable, and trackable way to organize your work and manage change as you develop functionality.
And best of all, Salesforce CLI and DX projects make creating unlocked packages a snap. You can install unlocked packages in any Salesforce environment: scratch orgs, sandboxes, trial orgs, and production orgs.
If you want to know more, check out the Unlocked Packages for Customers module.
Assemble the Team
Perhaps you’ve heard the expression “No person is an island.” This same adage applies to teams. In many companies, your Salesforce production org has many stakeholders. As you get ready to embark on the journey of package development, one of the first tasks involves how to untangle your org. Before you begin, it’s important to include the right people.
Package Development Readiness provides strategies for assembling your team in preparation for moving to package development.
Look for Ways to Untangle the Org into Packages
Evaluate all aspects of your development process to look for possible ways to shift to the modular, package-based approach. Look for distinct applications in the production org that are separate from everything else. Do you have distinct teams that build and maintain these applications? If so, you can isolate those applications into their own packages. AppExchange has many great examples of standalone apps that follow this idea of isolating a set of source and metadata into a single package.
Sometimes, you don’t have a distinct application that you can split into a package, but you have distinct parts of your org that you’ve worked on over time. For instance, extensions to one of your core apps could be released as packages. You can isolate all of the extensions you make in customizing your company’s sales process into a single package. If you can isolate the metadata that is specific to these parts, you can use that to develop a package.
You can also look for teams who already, or would like to, build, and deliver separately from everyone else. Find teams who are looking for opportunities to be more agile and flexible. Or teams who want to separate their changes from the larger change management process in their production org. These teams can isolate their metadata and store them in their own package.
Rome Wasn’t Built in a Day
If your organization has a mature or complex org, the shift to packages needs to occur over time. Your production org is your most prized possession, so plan your transition thoughtfully. Use the guidance in this unit to identify parts of your org that you can shift to packages. Shift one package at a time and continue to evaluate and improve your process.
Now that you know more about the package development model, it’s time to get your fingernails dirty by trying it out.