Imagine a New Source of Truth

Learning Objectives

After completing this unit, you’ll be able to:

• Describe how the models for org development differ from modular package development.
  
• List the advantages of package development.
  
• Describe the key characteristics of a package.
  

All the World's an Org

A famous thespian, or perhaps it was a Salesforce visionary, once said, “All the world’s an org.” Traditionally, the center of this world has been your production org, and you’ve performed much of your development within the confines of a sandbox or production org. (If you are an AppExchange partner, your world is a bit different. However, the tools introduced in this unit are available to you too, so read on.)

How You’ve Traditionally Managed Change

If you completed the Org Development Model module, you might remember Calvin Green, the admin for Zephyrus Relocation Services. As Zephyrus grew, so did the complexity of its production org. To manage this increasing change, he began his path to adopt Salesforce modern development tooling to manage his team’s application lifecycle.

Let’s look at how your development team might work using the Org Development model.

You are a development lead for a fast-paced high-tech company. For your release, you need to customize the core CRM app and you also want to build an internal application for your company. Your first step in development is to make sure that you get the most up-to-date snapshot of your production org. In the org-based model, your production org is the source of truth for all your code, configuration, and customizations.

Regardless of what you’re building, you ultimately create deployments that are scoped to your production org. As you see in the diagram, even if you have multiple teams working on separate development projects, they develop and release their updates with the same deployment. Everything goes into one package.xml.

For the first release, let’s say you are working on two new projects:

For the second release, you’re making some minor updates. However, you still release and deploy both projects at the same time to the production org:

Your developers and release managers view the org as an intermingled set of code and customizations. To drive the point home, look at the diagram again. The final deployment is not scoped to the Time Off Manager app or just the CRM extensions; it includes all changes to the org.

As you develop, you have to track what you’re changing to make sure that you know what to deploy to the production org. Your changes intermingle with what others have changed, so this process can be tricky and somewhat manual. If you use source control in this process, this same sense of intermingled code and customizations is reflected in the source control system. You align your source repository to the org as opposed to a part of the org (for example, the Time Off Manager app).

But what if you find that your intermingled happy soup gets so complex and you need a better way to manage change? Are you looking to follow a more traditional development model to deliver and release apps and solutions?

Manage Change with Package Development

As Zephyrus continued to grow, its releases became more and more complex. With multiple development teams and multiple Salesforce admins, Calvin wanted to pursue a way to decouple projects from the huge release train. The package development model streamlines the entire development lifecycle, with benefits like:

• Improving team development and collaboration.
  
• Modular development process with specification of dependencies among packages.
  
• Versioning to help with change management
  
• Facilitating automated testing and continuous integration.
  
• Making the release cycle more efficient and agile.
  
• Improved version control system (VCS) synchronization through change-tracking of Setup features
  
• More fine-grained visibility and clarity into the change management of your production org
  

What does this mean? Instead of building code and customizations for the org, you create a package (a logical set of code). A package is a release artifact that is a group of related code and customizations.

The grouping of components within a package can represent lots of things. The package can be a set of customizations created to support a sales team. A package can be the Lightning components, objects, and workflows for an application being built in the org. A package can be the extensions you’re building around a managed package that you installed from AppExchange.

With this new process, you’re able to organize your org into a set of packages. By organizing your source and metadata into packages, you better understand the relationships between the metadata components in your org. The bigger your org gets, the more important this process becomes, so plan early and always be thinking about how to organize your org.

A VCS is a developer’s best friend and plays an integral role in the package development lifecycle. You store all source for your packages in a source control repository, where the source of truth is maintained. You build scratch (development) orgs from that source, so you can work specifically on your package. We provide change tracking features to monitor what you’ve created, updated, and deleted in the development org. You can easily pull that modified source down to your file system and check it into your VCS.

Package development gives you more flexibility in managing your teams and releases. You can assign teams to own a particular package. Development teams can develop separately and build toward a release of the package, and not a release of updates to the org. With this agile model, you can have more frequent, independent releases, as you can see in the development, build, and deploy flow.

For our enterprise customers, we have a special package type, called unlocked packages, which are especially suited for internal business apps.

How Unlocked Packages Provide Flexibility

Let’s look at how unlocked packages change the way we’d release the CRM customization and Time Off Manager app.

In this example, for the first release, you’re creating two new projects. They are both versioned as 1.0 and can be built, then deployed to the production org separately using Metadata API.

For the next release, you once again can build and deploy each package version independently to the production org. This way you can maintain distinct and different versions for each release artifact (package).

This process also extends to CI and CD. Building packages lets you create test plans designed specifically for the project. You can automate the test plan to ensure a continuous level of quality by running tests through multiple environments as source is modified through the VCS.

Resources

• Developer Guide: Salesforce CLI Command Reference
• Developer Guide: Salesforce DX Developer Guide
• Trailhead: Quick Start: Salesforce DX
• Trailhead: Unlocked Packages for Customer