Use Package Development for More Flexible Releases

This unit describes why Calvin and his colleagues decide to move away from change set development models to package development. Other teams might find different aspects of package development compelling. As you read through this unit, consider which choices you would make for your team and which aspect of package development you find most compelling. Get hands-on by working through the module listed at the end of this module to learn the process and make the most informed decision about what will work for you.

Over time, the number of projects and contributors for each release to their production org keeps growing at Zephyrus. This is great for the users. The company’s consistent application of the ALM steps supports good turnaround time for enhancement requests while keeping disruptions to a minimum.

Coordinating these changes, especially so many unrelated changes from multiple teams, is becoming a real headache for Calvin, however. The releases continue to increase in size and complexity. He worries that, given the difficulty of aggregating and testing changes for all the projects in a release, features Zephyrus staff rely on will break.

With so many changes to coordinate and track in each release, Calvin realizes he’d rather spend that time making changes. He also considers that teams customizing Salesforce at Zephyrus could be more productive if they spent less time coordinating their changes with those from other projects.

On the Salesforce Trailblazer Community, Calvin asks the other members for advice on how to manage so many projects in each release. They tell him about a new Salesforce development model that provides more flexibility for release management. It’s called package development.

In package development, you manage different customizations as separate packages, not as one big release of changes to the org. Remember how in change set development you manage a set of changes from multiple projects as though they’re going into one container? When releases become so complex that it makes sense to manage the org as multiple containers, it’s time to move to the package development model. If your team is already building modular release artifacts on other platforms, they’ll find some similarities working in package development.

For example, a package at Zephyrus might contain any of the following customizations.

When you’re working in a package development model, you build a release artifact you can test and release independently from artifacts for other projects. Instead of a set of changes relative to production, your team creates a package that contains all the relevant metadata. The metadata in the package includes both changed and unchanged components.

Organizing metadata updates by packages also helps you create a better mental model of how the metadata in your org is structured. If you want to manage your org as multiple containers, each package represents one of those containers.

A package version is a fixed snapshot of the package contents and related metadata. The package version lets you manage what’s different each time you release or deploy a specific set of changes added to a package. If you’re introducing metadata changes to an already deployed package, you upgrade from the current package version to the newer package version.

Calvin is fired up by the potential productivity gains of moving to package development. He makes the case to Ernesto, the CEO, and directors from other departments creating Salesforce customizations. He focuses on three main points.

In package development, your source of truth is the metadata in your package project. This makes it easy to integrate to a VCS that can help your team manage the project changes they make.

In change set development, the source of truth is a combination of the metadata already in the environment and the last build of the change set. On its own, a change set doesn't present the complete picture because it contains only what’s changed.

There’s a development environment available in package development called scratch orgs. Scratch orgs play a key role in significantly reducing the changes Calvin and his team need to track for each release.

Scratch orgs are empty orgs (no metadata or data) that are easy to create and dispose of as needed. You can configure scratch orgs to be different Salesforce editions with different features and preferences. What’s more, you can re-use and share the scratch org definition file with other team members, because it’s part of the project integrated into the VCS. This way, it’s much simpler for you all to work in the same org configuration while each having your own development environment.

When you use scratch orgs for development, you first push the source from your project in the VCS to sync the scratch org with the same metadata. If you are planning to use Setup for development, the changes you make are tracked automatically. You can pull down the modifications you made to include them in your project and use your VCS to commit all the changes.

Tip

How does Calvin know which components are supported in source tracking? The Metadata Coverage report shows you whether metadata types are supported in source tracking, Metadata API, and other metadata channels. This dynamically generated report is your best source for metadata-coverage information. To access the Metadata Coverage report, go to https://developer.salesforce.com/docs/metadata-coverage.

In package development, you can maintain separate release schedules for each package. You use packages to segment the ownership of org metadata, so each project has its own package plus any dependent packages. You can manage the upgrade of individual segments independently through each subsequent package version, allowing you to maintain separate release schedules.

What is a package dependency? A metadata component can be in only one package at a time. If more than one package needs the same component, you can devise a modular package strategy for that component. A package containing one or more metadata components shared by multiple packages is a package dependency.

Each package (and any package dependencies) can be tested in isolation from all other metadata in the org. Isolating the metadata like this into packages is what gives you the flexibility to version these sets of metadata (packages) independently. This is also what gives you the flexibility to release the packages independently.

Each of the three development models has its own module in Trailhead. By working through each module, you’ll learn how to create customizations for Salesforce using that development model.

• Change Set Development
• Org Development
• Package Development