I have a quick question on the best practices for managing the Parter Business Org when developing Second Generation Packages. As Parter Business Org act as the Dev Hub for the second generation packaging and the dev hub owns the packages (which can not be changed once the package is generated), what is the best practice on handling CI/CD process. Before we deploy the final package to production which will be on Parter Business Org Dev Hub org, we need to build and test the packages many times as beta features in a CI org. We many times need to have many CI processes which will have the same package names. These are just beta packages and we don't want to deploy these to the Parter Business Org yet.

So what is the best practices being followed for this? Do you guys use the same Parter Business Org for all these purposes (I hope this is not the case) or you guys request new org with dev hub for incorporating CI/CD purposes.

I would like to get some suggestion on what is the best practices being followed in this.

Thanks, Bikram.


You can, and should, use the same org. Uploading a package to your Dev Hub does not install it. You can install them later, but only the installed version will affect your org. Also, a new feature, coming in Winter '21, will allow you to clean up (delete) package versions that you no longer need. There's really no reason not to use your primary org as the Dev Hub. Note that trial orgs and other free orgs only have a small handful of daily package limits, so it's not practical for an ISV/OEM partner to use such an org for production packages. Also, you still can't unlink namespaces from a Dev Hub, so make sure you choose the right Dev Hub before you get started.

  • Thanks @sdfcfox for the details. Appreciate it. Sep 8 '20 at 3:31

As per your statement you are using your PBO as your dev hub, which is the right approach. I just wanted to expand on that point first.

As per Salesforce requirements, your Dev Hub must be your PBO if you are a partner. This is not covered in the core documentation but is stated in other documentation, such as the ISV-centric stuff. I also verified this via a partner forum posting and had the following response from Vivek Chawla (Salesforce):

As a partner, you should be using your PBO as your DevHub. Full Stop. There are some very good reasons for this.

He attached the following slide from "Salesforce DX for ISVs - How to Get Started":

How to Get Started: Qs about Dev Hubs

When we run CI, we actually have the CI service create a brand new scratch org (with the package namespace) for every pull request targeted at specific branches (or release candidate branches) and ensure that we push our package metadata to it then run all apex and jest tests.

When we are happy with the content we create a package version. Once that is created we manually create a clean scratch org (with no namespace) and install the beta there, run all the apex and jest tests, perform basic smoke tests and (depending on the scale of change) have the QA team run regression tests and/or invite professional services to try out the beta. Only when we're happy do we then promote the package version to become a full release.

We do install our app on our PBO, since we do use some of the features ourselves, but this is not its primary usage.

  • Thanks a lot Phil for the great details. Appreciate it. Sep 22 '20 at 5:17

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.