2

Consider a scenario where a managed package is deployed and is used in a specific region (Western region).Now a new customer in another region (Eastern Region) needs some core level changes in that module which wont be suited for western region.To handle this the planning is to have a separate Repository for eastern region make necessary changes and make the package from the Repository and for introduction of new improvements both repository (Eastern and western) needs to be synchronized periodically.

Is there any other better ways to handle this?

3

The exact tools that you're using will dictate the precise process, but the general idea is that you should be using three distinct code bases, not two. One is at the top of the hierarchy, which we'll call Core, which contains the central logic for the other two code bases, Eastern and Western. Any changes to Core should be synchronized to Eastern and Western, while changes to just Eastern or Western would not be synchronized back to Core. Core does not actually represent a necessarily "functional" version of your code base, but simply a template for the other two code bases to get updates from. The Eastern and Western code bases should refer to two separate managed packages as a matter of simplicity.

There's going to be downsides any way you look at it, but having three code bases is going to introduce a minimum number of headaches for developers, and having just one managed package for Eastern and one for Western is going to minimize the number of headaches for clients, except for the precious few that may decide they installed the wrong version for whatever reason. It would be theoretically possible to build a set of three managed packages, where a client would first install Core followed by either Eastern or Western, but it's rather difficult for developers to work with, and requires extra steps from clients to install.

0

Before embarking on the complexity of separate branches (including the pain of merging changes) and separate managed packages (two security reviews), I suggest you review what is common and what is different for the two regions. (And perhaps consider how many other regions there may be in the future.)

In software in general, many products come as a single "package" but can be configured to handle different regions and and alternate functionality. In a Salesforce app there are a wide variety of configuration mechanisms that can be used post-install and things like custom settings can be used within the package to swap functionality.

If the differences are limited, you might be able to decide to deliver a single managed package that is the result of everyone working on a single code base (the simplest arrangement) or the result of two "region" branches being merged into a single "head" branch.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.