Rob Cowell · 29th November 2023
Bringing DevOps to Salesforce with the package development model
Salesforce development teams have more options than ever for delivering changes between environments. While manual deployments still work, they quickly become cumbersome at scale. This is where packaging comes in – providing a way to bundle customizations into modular units. But with multiple package types available, which is the best fit for your needs?
In this post, we’ll break down the pros and cons of Unmanaged Packages, Unlocked Packages, and Managed Packages. You’ll learn when each excels, along with tips for integrating them into your workflow as your new Salesforce development model.
What is the Salesforce package development model?
The package development model brings a modern approach to Salesforce development. It introduces familiar software techniques like the use of a version control system and modularization of applications. These are not common in traditional Salesforce implementations.
With packages, solutions start as code and metadata in your development environment, and are committed to Git repositories using services like GitHub, to better support effective change management. The development lifecycle often begins in scratch orgs – temporary environments made for building changes. Components get bundled into packages and deployed to longer-lived orgs. The package approach encourages a modular architecture, with solutions split into smaller pieces within namespaces to avoid future conflicts as customizations grow.
This contrasts with the more traditional org-driven model. Customization typically happened directly in sandboxes, and changes moved through manual export and import between orgs. There was no packaging or automation element. This org-driven method allows monolithic code in a shared namespace and with enough changes, collisions happen when using this model. Refactoring then becomes expensive.
What are the advantages of Salesforce package development?
A key benefit is the support for modular, iterative development. This approach breaks down the development process into smaller, manageable modules, allowing teams to focus on specific functionalities one at a time. This not only streamlines the development process but also facilitates easier maintenance and updates in the future.
Another significant advantage is that it provides a source of truth. In Salesforce package development, all components and dependencies are defined clearly, ensuring that every team member has a consistent and up-to-date view of the project. This centralized source reduces conflicts and discrepancies, which are common in large-scale developments.
Package development also greatly increases flexibility in release management.. Teams can manage different versions of the application more efficiently – can roll out updates, patches, or new features without disrupting the existing system, providing a seamless experience to end users.
It also facilitates easier organization development, simplifying the process of scaling and modifying the Salesforce organization structure as the business evolves. This adaptability is crucial in today’s fast-paced business environment where changes are constant.
Improved auditing is another critical advantage. Package development provides detailed tracking and logging of changes, making it easier to audit and review modifications. This feature is particularly valuable from a compliance and governance perspective, ensuring that the development adheres to required standards and policies.
Support for Continuous Integration/Continuous Deployment (CI/CD) is an integral part of package development. This methodology allows for the automatic testing and deployment of new code, reducing the time and effort required for manual processes. It ensures that new features and fixes are integrated smoothly and efficiently into the existing system.
The package development model also allows for easier accommodation of feature requests. With its modular structure, teams can quickly and efficiently incorporate new features or changes as requested by stakeholders or users. This responsiveness to user needs is crucial for maintaining relevance and competitiveness in the market.
The evolution of Salesforce packaging
To understand the progression of packaging, we need to go back in time. Salesforce originally launched with only one packaging model – now referred to as First Generation Packaging (1GP). 1GP provided the building blocks, such as unmanaged and managed packages. But over time, limitations emerged, including the lack of source control, upgrade challenges, and namespace constraints.
Salesforce listened and responded by releasing Second Generation Packaging (2GP) in 2014, as part of the Salesforce DX approach to Salesforce package development. This new model unlocked capabilities like unified namespaces, higher version numbers, and built-in support for Continuous Integration tools. 2GP introduced unlocked packages as the preferred delivery mechanism for componentized, source-driven development. It also updated managed packages to work within this model, while maintaining their security review and distribution capabilities.
The result was a flexible, modular framework which addressed the needs of both large enterprises and app vendors. Source control, dependency management, and automation became integral parts of packaging.
While 1GP is still supported, 2GP aligns much more closely with modern development practices. As you explore packaging options, keep this evolution in mind. Leverage unlocked packages for efficient development, and tap managed packages when broader distribution is the goal.
Unmanaged packages: simple sharing
Unmanaged packages represent the original packaging model that Salesforce started with. They provide a simple way to bundle customizations and share across orgs. The main advantage of unmanaged packages is flexibility. You can customize and edit the code after installing without restrictions. This makes them handy for collaborative development across teams.
To create an unmanaged package, you select components in the Salesforce UI and upload them. This generates an installation URL that recipients can use to install in their org.
However, it’s important to realize that unmanaged packages also have some key limitations:
- No built-in version control or upgrade process – manual updates required
- No namespaces – higher chance of conflicts
- Metadata is not source-driven – selected from org rather than version control
- Limited alignment with DevOps principles and tooling
Given these constraints, unmanaged packages now serve niche purposes such as distributing demo apps or providing starter solutions. They allow quick sharing and collaboration, but scale poorly.
Unlocked packages: modular and flexible
Unlocked packages bring granular control and modular development. By breaking solutions into discrete components, these packages streamline sharing across environments like sandboxes and your production org.
Change sets provide similar functionality but unlocked packages add namespaces and versioning on top. This aligns perfectly with DevOps practices like Git workflows and CI/CD, as they better support using source control for development, automating packaging and deployment, and provide greater flexibility to deploy fixes and updates.
The main downside is that managing dependencies across packages can introduce complexity. With planning and automation, this can be overcome to utilize unlocked packages for efficient delivery. You should aim to structure your metadata into modules that can be easily versioned, making use of namespaces to avoid conflicts and keep functional boundaries between different segments of your code.
Org-dependent packages: working around dependencies
Salesforce also offers Org-dependent unlocked packages to address dependency challenges. These packages defer compilation and validation until installation time rather than packaging time. This means you can rely on metadata in the target org even if it’s not in your local project or scratch org. The dependencies don’t have to be fully resolved to create the package.
Org-dependent unlocked packages shine for large, complex Salesforce orgs which have been built up over many years. Refactoring years of tightly coupled changes into modular architecture is extremely difficult.
With org-dependent packages, you can work incrementally. This means that you can start delivering features in a modular way without having to untangle all the legacy dependencies upfront. This incremental approach provides an easier path to transitioning complex orgs towards a more modular architecture over time.
Managed packages: secured for distribution
Managed packages allow independent software vendors (ISVs) to distribute a commercial application on the AppExchange. By undergoing Salesforce security reviews, these packages provide trusted functionality to customers.
As a package provider, you typically develop using Salesforce APIs and tools like Apex and Lightning. Once complete, you submit the package for Security Review to validate performance, data protection, and access controls. After approval, you can list the managed package on AppExchange. Customers can then easily find, evaluate, and install your app in their Salesforce org.
Managed packages make it simpler for organizations to extend Salesforce without building from scratch. ISVs handle upgrades and maintenance behind the scenes while customers focus on configuration. The locked-down code also allows some customization while protecting the intellectual property and core functionality. For commercial distribution at scale, managed packages tick all the boxes.
So while unlocked packages excel for in-house development, managed packages open the door to secure app distribution across a broader customer base.
Choose your own adventure
Salesforce packaging provides you options, but also brings a level of complexity in picking the right approach for you. Here are some key considerations when deciding:
| Package type | Pros | Cons | Typical use case |
|---|---|---|---|
| Unmanaged | Highly customizable Allows direct code modifications No namespace requirements | No version control No automatic upgrades Editable code raises security concerns No support for managed package features | Sharing code and configurations for learning Distributing sample solutions Collaborative development Used by professional services for customizable common solutions |
| Unlocked | Customizable with version control Allows code editing Supports managed package features like namespaces | No automatic upgrades Manual upgrade process Security concerns with editable code Requires Salesforce DX and source-driven development | Deploying reusable components across organizations Sharing modular solutions Facilitating internal collaboration and development |
| Managed | Automatic upgrades Enhanced security with non-editable code Supports features like namespaces Version control | Limited customization Requires namespaces 2GP requires Salesforce DX and source-driven development | Commercial app distribution Distributing apps on the AppExchange Protecting intellectual property |
By mapping your use cases to the strengths of each package type, you can optimize your path to painless delivery on the Salesforce platform. Packaging is just one piece of the DevOps puzzle – but an important one to understand in bringing harmony to your process.