Convert to a Managed Package
Learning Objectives
- List the benefits of using a managed package.
- Explain how managed packages encourage contributions from end users.
Before attempting the Hands-On Challenge at the end of this module, make sure you've completed the steps leading up to it, in this module and the preceding modules in the Build Applications with CumulusCI trail. The Hands-On Challenge will instruct you to do your steps in your Trailhead playground instead of in a sandbox like Tasha did.
In this module, we continue with the story of Tasha, Maddie, and Isabel; and their efforts developing an open source app with the potential to benefit thousands of food security organizations. Tasha is a Salesforce administrator at Compa Food Security Network. She’s the primary coordinator of the Food Bank app. Tasha’s college friend Maddie manages logistics at a food bank called Hunger Northeast, and she’ll be one of the many beneficiaries of the completed app. Isabel is a friend of Tasha’s who is a developer and consultant with Advocate Partners.
The team has created a GitHub repository for their project, captured their customizations made in a scratch org, and created a sample dataset for users. It's now time to take the next step and make their project available to food security organizations using Salesforce.
The Benefits of a Managed Package
Tasha is pretty excited that she can easily set up a new scratch org that already contains her Food Bank objects and some sample data. She’s eager to share the GitHub repository with Maddie so that Maddie can start setting up the org for Hunger Northeast. But Isabel reminds Tasha that the goal isn’t just to share an ice cream sundae—the way a single org is built. To make it easy for food bank administrators around the world to create their own org sundae that meets their needs, Tasha and Maddie can develop a new flavor of ice cream—a new “Food Bank” customization for Salesforce—that serves as the foundation on which other food banks may build their sundaes.
So far, Tasha has been working in the test kitchen, developing and testing the new flavor. At this point, she could share the recipe (the steps she followed to create her project) with the food bank community. Isabel proposes another idea, though: just like it’s more efficient to buy a pint of ice cream than to make it from scratch, it’s more efficient to distribute the Food Bank customizations as a managed package that anyone can install—and use to build their own org sundae!
In the Salesforce world, a managed package is a set of components that have been developed together in one org (called the packaging org) and can be installed together into other orgs (called subscriber orgs).
Releasing this project as a managed package can take a bit more work, but has several benefits:
- Isolation: Components in managed packages are installed in their own namespace. A namespace is a way of grouping and isolating components so that they don’t collide with customizations from other packages, or in the other layers of the org sundae. The unique namespace will be added to all components within the package.
- Upgrades: Managed packages provide a proven mechanism for installing and upgrading Salesforce customizations. Other organizations using the project can easily upgrade to a newer version without fear of overwriting their customizations.
- Manageability Rules: Managed packages impose constraints on what you can and cannot change in a released package. These act as guard rails to reduce the chance that package developers make changes to the package that break customizations by admins.
- Encouraging Contributions: The metadata inside a managed package can’t be edited by end users in their orgs. This creates an incentive to contribute changes to the package in the project's GitHub repository instead, so the changes will be included in the next release and subsequently used in all orgs with the package installed. Bringing changes into the managed package makes it easy for users to upgrade their org sundaes, and ensures that the whole application works together.
Because she's been using version control best practices, Tasha is already poised to package her work and share it with others. She has the metadata for the package in her GitHub repository, her next step is to create a packaging org, and then use CumulusCI to deploy the package metadata into the packaging org. We’ll pick up there in the next unit.
