Release Strategies for Salesforce Managed Packages: Our Experience

Updated on March 30, 2021

As a Salesforce partner, we deliver two pre-packaged applications to our customers via Salesforce’s AppExchange – Ascendix Search and AscendixRE.

When one of our applications is installed in a customer’s Salesforce organization, it is installed as a managed package. In this post, we will talk about versioning and how we tackle it.

What is a Managed Package in Salesforce?

A Salesforce managed package is a collection of application components distributed as a single unit on AppExchange (a Salesforce marketplace), allowing Salesforce app developers to seamlessly distribute updates including new features, improvements, and bug fixes.

Managed packages also provide benefits such as the protection of intellectual property and built-in versioning allowing us to support multiple versions of our application simultaneously.

Salesforce Apps Distribution: Available Options

Salesforce offers two ways applications updates can be distributed:

1. As a major release
2. As a patch release

Major Release

A major release allows the package publisher to include new components and modify existing components (with restrictions).

This is typically how new features are implemented, but a major release also comes with some disadvantages.

Disadvantages:

#1 Only Admin can manually install the update

First, a major release cannot be pushed to existing deployments (Registered ISV partners can request Push Major Upgrade functionality by logging a case in the Partner Community.  However, pushing a major upgrade entails a higher degree of risk as it can impact existing functionality in a subscriber’s organization) and instead requires the admin in the target organization to manually install the update.

This is purposeful and prevents a publisher from pushing breaking changes.

 

💡 Still a Salesforce Classic User? Learn Why You Should Hurry Up with Migration to Lightning

 

#2 Each new Major Release = a new branch

Second, with each new major release, a new branch is created.

What this means simply is if there are multiple installed versions of an application, if a bug exists in one it may exist in another requiring additional effort to patch the bug and push updates to each version currently in use.

Patch Release

A patch release allows the package publisher to change the functionality of existing components, but not add or remove any.

This is typically how bugs and other errors (such as those sometimes introduced with Salesforce seasonal updates) are resolved.

However, we have found patches are a convenient way to push out new functionality to our customers without modifying the structure of the package.

One of the main advantages of a patch release is they can automatically be pushed to a customer’s organization upgrading their installation to a new version of your package.

For example, the following changes are allowed:

1. Adding new methods to Apex controllers
2. Extend the functionality of a Lightning Component
3. Add files to an existing static resource
4. Modify a permission set

What can’t you do in a patch?

1. Modify the accessor of a class (e.g. change from public to global)
2. Add a new Apex class
3. Add a new Lightning Component
4. Add a new object or field
5. Add a new static resource
6. Add a new permission set

Our Experience

At Ascendix we have used this strategy to add new functionality to our managed packages, which reduces how often we need to plan major releases.

This allows us to push improvements to our customers without inconveniencing them.

It also reduces the number of releases we must support concurrently, allowing us to focus more energy on product improvement instead of product maintenance.

Examples of features we have added to our Ascendix Search app via a patch release:

Export to Excel

Insights

Composer 

While these look like new components, they are actually extensions of existing ones.

For example, the Composer dialog is embedded within the parent component using an aura:if (#1) conditional tag and a modal dialog (#2) directive:

We define the user interface for the new feature within the context of the parent container.  Logic is added in a similar way in both the Lightning Component and Apex controller.

This approach works best with components having a specific use as shown in the examples above.

Patch Limitations

For components needing to be displayed multiple times such as within an aura:iteration, this approach wouldn’t be appropriate.

Using a patch can also increase technical debt in your project since the components will become more complex as additional features are added.

Best practices tell us we should keep code simple, readable, and broken up into small, manageable blocks.

To mitigate these risks, with each major release we move features added during patches into new components where they can be separately maintained, keeping our code healthy and clean.

Whether you are planning a major release or a patch, there are many factors to be considered.

When implementing a new feature a major release may not always be required and a patch may be a more appropriate option.

Depending on your requirements, when keeping the limitations in mind you have multiple options.

Ascendix Technologies: Salesforce App Development Company

If you need assistance with your release strategy, Ascendix may be able to help you come up with a plan keeping your customers happy by reducing the frequency of major releases while still providing them with the latest features you have to offer.

Appexchange app development is one of our key Salesforce consulting services. Having over 150,000 customers worldwide, Salesforce is the right place to access the most advanced and tech-savvy companies. Having our own AppExchange apps, we know all ins and outs of the Salesforce app development from the very idea to passed security review. Contact us to get your own AppExchange app