3

I want to deploy an application on the AppExchange and I need some explanations.

My application contains several editions (Edition 1, 2, 3 and 4) with differents features. Superior edition contains the features of inferior edition. For exemple Edition 2 contains all the features of Edition 1 plus some additional features.

A client can have users with differents Editions. For example, a client wants 50 licences of Edition 2 and 10 of Edition 3. And then, he will award the licences to differents users.

I want to deploy this 4 packages on the AppExchange. All of packages will have some redundant source code but it doesn't matter.

I have several questions :

  • Will I have 4 differents applications on the AppExchange (one for each Edition) ? So I have to pay 4 security reviews, right ?

  • How can I maintain my source code to avoid having four times the same code. For example, I have a trunk and three branches. But if I have to modify a piece of code that is common to all Edition, I don't want to do it four times ! Is it possible to have a trunk with the common code, a branch for Edition 1, an other for Edition 2 and a third for Edition 3 and choose which one I want to compile for create the good package ?

  • I see the Extension package system in SalesForce but I don't really understand. Can I use this in my case and how ?

Maybe I'm not starting on the right way, so can you provide me some informations for manage my four packages ?

Improve this question

2 Answers 2

Reset to default
2

I think Extensions is what you need to use - I would store all the common code in a 'core' package and have everyone install that. You can then make methods in the package global so they can be called by classes in the other packages.

When a package is an extension, it creates a dependency...so I would build all your packages on top of the core package, and probably Superior on top of Inferior so you can upgrade people more easily by installing the Superior package, rather than requiring them to remove Inferior and add Superior.

I believe that all packages, including extensions would be treated separately for the purposes of security review.

Improve this answer
4
  • 1
    I was about 80% through the same answer when you posted Peter :) I would add to this, each package will need it's own package/dev org. The extension packages will have the core package installed, which will create the extension dependency. I think your best bet for managing releases is some sort of CI automation.
    – greenstork
    Oct 2, 2014 at 15:06
  • Ok, thank you for your answer. But how my app will be displayed in the AppExchange ? It will have four differents apps corresponding to the four Editions ?
    – SF_user
    Oct 2, 2014 at 15:08
  • Up to you really...so you might not display the core package unless it was useful in and of itself - but basically, the AppExchange is the sales outlet - so you display what you think customers would be looking for/looking to buy
    – BritishBoyinDC
    Oct 2, 2014 at 15:47
  • 1
    It sounds like an extension package is the way to go. For the CI automation mentioned by @greenstork, we've put a lot of work over the last year into building a CI automation process that takes a lot of the complexity out of developing and releasing an extension package. We're wrapping up the final changes over the next few weeks to make it more easily reusable by other projects. You can follow along at github.com/SalesforceFoundation/CumulusCI
    – Jason Lantz
    Oct 3, 2014 at 3:26
2

An alternate pattern to consider is rather than sharing the code via a core package to share the code via your source control system. Subversion has svn:externals that allows code from multiple locations to be checked out into one project. So your 4 edition code sets would each pull a copy of the same core source code which the Force.com IDE or Ant tooling would then push into the 4 packaging orgs.

The benefits of this approach (compared to having a core managed package) are:

  • Avoids the need to introduce global classes and methods that then can't be changed so allowing refactoring
  • Avoids having to re-package and re-deploy the core package to make any changes there
  • Reduces your managed package count by 1
  • Customers only need to install 1 managed package not 2
Improve this answer

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.