When working on multivendor Salesforce projects, aligning deployments and the development lifecycle becomes challenging.
Especially for immature teams.
Traditionally, in Salesforce, developers got used to the org development model.
You do the development in scratch org or developer sandbox, then deploy it to the sandbox for the user-acceptance testing, and finally do a release.
It works well, but as long as the organization grows, the production organization becomes very complex.
For instance, I've been working on multiple multivendor projects where release management was complicated and required all parties to sync with each other.
It can slow the development, e.g., if you need to stick to the deployment schedule.
In the worst-case scenarios, it can even introduce bugs and incompatibilities.
In this article, I will describe a more agile and flexible development model that can keep the source of truth in the source code rather than in an organization.
I will split this into two parts: in the first part, I will talk about the model in general, and in the second, I will discuss how to start implementing a package development model.
The problem of the Organization Development Model
Working in a multivendor environment and a shared metadata brings specific challenges.
Even when all teams use SFDX, it might be difficult because some vendors might want to manage their metadata separately.
It requires strong guidelines and governance, which immature organizations lack.
There are some solutions to such problems.
For instance, aligning the teams on what areas they're working on to ensure their changes do not affect others.
Also, developers tend to prefix the file names to isolate parts of the code base they work on.
The problem is that the release uses the same deployment even if multiple teams work on separate projects.
Since you need to align and plan the release, it becomes difficult to manage and test.
Sometimes you need to have a release schedule. Then, you cannot release even minor fixes independently, and everything has to go simultaneously.
The same goes for source control.
Since you essentially work on the same metadata, you have to work on the same source code, which could introduce more difficulties in managing the PRs and code changes.
What is a Package Development Model?
Fortunately, there is an alternative way.
Another approach to the development is the Package Development Model.
Originally, packages used to be for partners who wanted to build and distribute on AppExchange.
It's a new shift in the development, where we want to decouple the projects from a single release.
This approach can help complex organizations to streamline the entire development lifecycle.
Here are some of the benefits:
- Enhancing team development and collaboration.
- Modular development process with specification of dependencies among packages.
- Versioning helps 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 the Setup features
- More fine-grained visibility and clarity into the change management of your production org
Source: Imagine a New Source of Truth | Salesforce Trailhead.
Essentially, you create a package instead of building code and customizations for the org.
The package is the release artifact, a group of released code and customizations.
You can add anything to the package, from Lightning Web Components or customizations to the AppExchange package extension.
When you split your source code into packages, it becomes easier to understand the relationships. The overall process becomes clear.
Following the package development model helps you have the source of truth in the code repository rather than the organization.
The main benefit is that package development gives you more flexibility in managing teams and releases.
For example, you can assign teams to their particular package. Then, teams can develop and build toward the release independently.
For each package, you can have your version number and can have different versions at the same time.
You can also leverage the CI/CD, and testing becomes easier. You can plan and design it specifically for each project.
You should organize the source code into packages based on the group of features or customizations you want to deliver together.
Each package should be created as a local metadata directory and contain a configuration file for creating scratch orgs.
It can also contain data you want to load into orgs for development and testing.
Note: When you build the package, behind the scenes, it creates the org based on your configuration, installs all the dependencies into that org, deploys the metadata, and runs all the automated tests.
You can test and release the package independently.
If multiple packages get built and released together, you can organize these packages into a single DX project.
Conclusiton
In conclusion, the Package Development Model offers a new approach to managing the development lifecycle and releases.
Teams can enjoy enhanced flexibility and more efficient release cycles by shifting from a centralized metadata to a decoupled, package-centric architecture.
This model streamlines the development and fosters a more organized and controlled environment for versioning and change management.
Embracing this methodology can lead to higher quality releases, reduced risks of bugs and incompatibilities, and a more harmonious environment among development teams.
Nikita Verkhoshintcev
Senior Salesforce Consultant
I'm a senior Salesforce consultant based in Helsinki, Finland, specializing in Experience Cloud, Product Development (PDO), and custom integrations. I've worked as an independent consultant building custom Salesforce communities and applications since 2016. Usually, customers reach out to me because of my expertise, flexibility, and ability to work closely with the team. I'm always open to collaboration, so feel free to reach out!
