Plan Your Move to Packages
- Identify use cases where you can shift to a modular (package development) approach.
- Identify a scenario that doesn't lend itself to package development.
Now that you understand how to use the new Salesforce DX tools and recognize their value, 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
These developer-controlled packages help mitigate some of the limitations of current technologies like change sets and the ANT Migration Tool. Unlocked packages provide a repeatable, scriptable, and trackable way to organize your work and manage change as you develop functionality.
And best of all, the 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.
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.
Are you a developer who has only worked in the Change Set development model, or did you start your career as an admin? Then the package development model is a perfect opportunity to embrace a more agile and flexible development process.
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.