1

At this point, my team and I have read through multiple trailheads, docs and posts on the following. We have a lot of good ideas, but still a key issue remains.

First, please verify this is the best practices org setup for ISV partners: - 1 packaging org (PDO) that will connect to AppExchange - 5 other PDOs where individual coders can do their development - 1 Staging PDO where all Devs can move their code - We'll use Github Repo as our 'source of truth' --- This means Dev, Staging and Packaging Orgs all get the latest from the Repo.

Second, how do we handle namespace with this model? As we see only Scratch orgs can be made to mirror the Packaging Org. Can we do the same with our Dev and Staging Orgs? If not, there are major conflicts in Github as we move code via Github to/from Packaging Org. We have had this already, and it's quite painful.

  • You don't have to use namespace references at all in your development. We (Salesforce.org, an "internal ISV") don't - virtually all of our products are buildable in non-namespaced scratch orgs. Your code just has to use dynamism anywhere you want to explicitly reference your own namespace. – David Reed May 12 at 21:59
4

First, please verify this is the best practices org setup for ISV partners

No, Scratch Orgs, not Partner Developer Edition Orgs, are the best practices in the current development model. Yes, each developer should have their own org, but it should be a Scratch Org. If you move to a pure 2GMP (Second Generation Managed Package) model, you don't move code to the Packaging Org at all.

Second, how do we handle namespace with this model? ... Can we do the same with our Dev and Staging Orgs?

You don't. This was a major limitation of the Developer Edition model of doing things, and this is what 2GMP/Scratch Orgs aims to solve.

If not, there are major conflicts in Github as we move code via Github to/from Packaging Org.

There shouldn't be. Migrating code should be relatively painless even in the old development model. The tooling supports automatic namespace translation, which was the original solution to the development problem. However, it's not entirely perfect. You should leverage Scratch Orgs to get the full benefits of proper namespace development.

| improve this answer | |
  • Once again, thanks @sfdcfox! – Ryan McNeely May 12 at 22:12
  • we'll go w scratch orgs and 2GMP. Do you have 1 trailhead or doc as reference? Part of the issue there are several available, and I'm not sure which to focus on. – Ryan McNeely May 12 at 22:15
  • Here is the documentation. developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/…. – Mohith Shrivastava May 12 at 22:19
  • 1
    Note that neither 2GMP push upgrades nor 1GP->2GP migration is currently GA. Push upgrades for 2GMP are in beta in Summer '20. Worth considering if either feature is a deal-breaker for you. – David Reed May 13 at 3:26
  • @DavidReed True. I made some assumptions: they don't already have a 1GMP (they're new), and probably won't need Push Upgrades right away (I was with an ISV for years and never needed it). Those are important caveats to consider, though. – sfdcfox May 13 at 3:28
2

As the other answer says you should be using the Scratch org for development and upon merging the changes from different branches you will create a new scratch org (automate this) and push and compile the source.

One key thing to note is you should create scratch of type "Partner Developer Edition"

In the scratch org config, it will be as below

{
  "orgName": "Partner Developer",
  "country": "US",
  "edition": "Enterprise",
 }

This will get you the necessary licenses and features that regular Developer Edition scratch orgs won't have.

| improve this answer | |
  • Thanks @mohith. I'll do it this way. – Ryan McNeely May 12 at 22:16

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.