Rocket ship badge DevOps Launchpad

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 typeProsConsTypical use case
UnmanagedHighly 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
UnlockedCustomizable 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
ManagedAutomatic 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.

Further reading