Break Up Your Metadata
Learning Objectives
After completing this unit, you’ll be able to:
- Describe how enterprise customers use unlocked packages.
- Describe how package development is different from change set development.
- Describe how you deploy metadata using packages.
Why Package Development Is the Future
If you completed the Package Development Model module, you know that modular, package-based development is a game changer. But perhaps you’re thinking, how can I put these principles into practice? How does this modular model make my life easier?
Whether you’re new to developing on the platform or a seasoned veteran, packaging is for you. As a long-time customer, the more you customize and build on the platform, the more complexity you create in your org. Your single Salesforce org has become a huge container for all the metadata you’re managing and interacting with. We refer to this horn of plenty as your “happy soup.”
If you rolled out Salesforce customizations recently, you deployed metadata to production orgs using change sets, or even unmanaged packages. This traditional development model is what we call change set development. Your development has occurred largely within the confines of a sandbox or production org.
The change set development application lifecycle involves moving org changes between development and test environments until those changes are released to your production org. But at the end of the day, the “source of truth” is the production org. Even if you track changes externally in a version control system, you know with certainty that everything resides in your org.
But now you have more options! In the package development model, the new and improved source of truth is your version control system. You use Salesforce DX projects to organize your source into package directories. Your end goal is to create packages using those directories that are versionable, easy to maintain, update, install, and upgrade.
With that said, moving to package development isn’t an all-or-nothing proposition. We’ll remove the mystery, and show you how to get started.
What Is a Package?
If you’re new to packaging, you can think about a package as a container that you fill with metadata. It’s a distributable unit of functionality.
Imagine that you’ve built a custom app for your employees to track expenses. You’ve included custom objects, Apex classes, Lightning components, and more. In the change set development model, all the metadata that belongs to that custom app is contained in your Salesforce org. However, it’s not isolated or organized in a way that makes it easy to upgrade and maintain. In the package development model, you organize that metadata into well-defined containers called packages.
By now, you won’t be surprised to know the most compelling reasons to use packages come down to metadata, that is, organizing your metadata. Without packages, your Salesforce metadata could start to get unwieldy.
Unlocked Packages to the Rescue
Salesforce offers several different types of packages, each with unique characteristics. For now, we’re going to work with a special package type, unlocked packages, which are especially suited for internal business apps.
Unlocked packages help you add, edit, and remove metadata in your org in a trackable way so you can reuse components and upgrade your Salesforce apps easier and faster. They encapsulate all the metadata changes and updates you plan to make.
Of course, your application, and thus the contents of the package, change over time. To track changes, you create versions of your package. Each version is an immutable artifact, a snapshot of the contents of your package.
In your production org, you can inspect which metadata came from which package version, and the set of all metadata associated with the package version. This inspection process is the same for packages you have installed from AppExchange.
No more spreadsheets to track metadata changes. No more sticky notes!
What Is an Unlocked Package?
With an unlocked package, you have a lot of flexibility. Your admins can make changes directly in production in response to emergency change requests because metadata in unlocked packages can be modified in a production org.
While unlocked packages give you the flexibility to make changes directly in the production org, remember that with great power comes great responsibility. Can you feel your Spidey-senses tingling?
Unlocked packages are developer-controlled. The installation of any new package version overwrites the changes made directly in the production org. It’s critical that admins communicate any changes made directly in the production org to the development team so that the package is updated appropriately.
So just what can you put in an unlocked package? Good news! You can put almost all types of Salesforce metadata and components in an unlocked package.
The Metadata Coverage report is the source of truth for metadata coverage information across several channels. These channels include Metadata API, source tracking, unlocked packages, second-generation managed packages, first-generation managed packages, and more. To access the Metadata Coverage report, go to https://developer.salesforce.com/docs/metadata-coverage.
How Do You Get Started?
Before we get to the good parts, this tidbit is really important and worth repeating—adopting Salesforce DX tools and development principles is not an all-or-nothing venture. You can take baby steps, or you can jump into the deep end. We don’t judge.
So, if you’re ready to expand your repertoire, where do you begin?
- If you’re new to Salesforce or starting a new project, you can follow the package development model right from the start.
- If you’re starting out with a large cornucopia of undifferentiated source, you can adopt packaging incrementally as you begin to carve up your metadata and organize it into logical containers.
You can start small by packaging components and schema that you can later reuse in multiple apps. When the time comes, you can define dependencies between the packages. You decide how fast to go and how much complexity you can absorb.
This flexibility is the power of unlocked packages.
Package Development with Salesforce DX
Now that you understand some of the core concepts of packaging, let’s take a look at the packaging workflow. For simplicity sake, let’s assume you are the sole developer and release manager, but another teammate is handling quality assurance (QA).
You start by creating a package associated with a directory in your Salesforce DX project. As the developer, you modify the metadata in your project, and changes accumulate. You use scratch orgs to develop and unit test these changes (1).
As the release manager, when you’re ready to share it with QA, you create a package version. QA installs the package and gets to work. You also use this package for unit testing and CI (2). During this process, you fix bugs, add new features, or modify existing features. You create a new package version and then start the unit testing process again (1).
This is the iterative nature of the package development model.
You repeat this process with QA until you have a good version, then you install this version in your sandbox for user acceptance testing (UAT), and eventually in production (3).
Installing the package version is similar to deploying metadata. You can install a package version in any org: a scratch org, sandbox org, or production org—similar to deploying a set of metadata.
And there you go! You now understand the basic application lifecycle for the package development model.
Now That You Released Your First Package
In the world of high tech and software development, there’s never much time to rest on your laurels. That next release is usually looming large. Now it’s time again to put on your cape and tights and get back to work and develop new features and customizations. And, you guessed it, a new package version.
You can create all the new versions you need as you change, add, or remove package metadata. Each package version has a version number (for example, 1.3.0.2) and you can use a package upgrade to apply these changes to an installed package version.
This process, modify metadata → create package version → test package version → deploy to production, can be done any number of times.
Ready to try it out? Let’s go build your first unlocked package.