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.

1
  • 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, 2020 at 21:59

2 Answers 2

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.

5
  • Once again, thanks @sfdcfox! May 12, 2020 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. May 12, 2020 at 22:15
  • Here is the documentation. developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/…. May 12, 2020 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, 2020 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, 2020 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.

1
  • Thanks @mohith. I'll do it this way. May 12, 2020 at 22:16

This site is temporarily in read-only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .