I'm trying out the capabilities of DevHub, in order to get product development from DE to DX org. This Trailhead helped me learning Devhub and DX+CLI functionalities.

I'm thinking of a way to migrate DE to DX, so we pull source+meta from DE to a scratch org. dev env., and keep in a VCS (Github private repository)

Accordingly, After moving to DX,

  1. DE must exist as it was, and we continue to publish the releases from here (Beta and GA to AppExchange)
  2. Source code will be in Version Control (VCS), kept in Private github.
  3. When we need to do a new release, we go ahead to get latest version checked out from github, do changes in a Scratch Org. spawned in Devhub. Push changes to github as well as DE., publish package from DE to customers/Appexchange

I would like to know if this is the right way to manage product development with Devhub?

I'm yet learning how to utilize DX into dev. so appreciate any thoughts/suggestions.

2 Answers 2


Yes, this is basically correct, but you'll eventually want to start using DX packaging, which allows you to break up your namespace into sub-packages for easier management and development. Basically, the only thing that changes is you push/pull to packages.

Pull from Github, create Scratch Org, push to Scratch Org, develop in Scratch Org, pull to local repo, update DX package, install to DE, commit, push to Github. Also, make sure you have a decent branching/merging strategy, that's pretty vital to this setup.

Not being an ISV, I haven't had a chance to test this out quite yet, but DX packaging should make it easier to manage your code, especially in the next release or two as DX matures.

  • 1
    A wonderful demo and template of the full ISV dev ops DX lifecycle from the enablement team: youtube.com/watch?v=xLjY-j5pf6c
    – Mark Pond
    May 23, 2018 at 4:43
  • I have a followup question to this, because my DE packaging org has namespace enabled I created a separate DevHub org. Now the flow that I am following here is 1. Pull the code from GitHub, 2. Create scratch org from DevHub Org, 3. sfdx force:source:push push push/pull changes from scratch and do local dev, 4. Once the changes are final deploy changes to DevHub org (not sure about why I need this step), 5. Push changes to GitHub (and using CI/CD capabilities) deploy this changes to packaging org, 6. Manually create release package from DE packaging org. Is this flow correct?
    – Yogesh D
    Sep 2, 2020 at 13:51
  • @YogeshD The situation has changed since this answer. In a modern setup, the Developer Edition (DE) org is only used to host the namespace; you do not need to use it as the packaging org. Everything is done with 2GMP (Second Generation Managed Packages). So, pull from GH, create SO, push/pull/deploy/retrieve, create package version, release. It's a lot simpler now than it used to be.
    – sfdcfox
    Sep 2, 2020 at 14:01
  • Interesting. Is it true for the old packages as well. I already have a package which was created using a DE org and I wish to continue the development on it.
    – Yogesh D
    Sep 2, 2020 at 14:56
  • @YogeshD There is no migration path from 1GMP to 2GMP yet, though this will probably happen at some point. For your old package, you create the package versions in the DH to install it in the DE. At no point should you be deploying your code to the DH.
    – sfdcfox
    Sep 2, 2020 at 15:00

I think Packaging 2.0 for ISVs (create managed packages packages directly from DX) is not fully baked yet. E.g. I cannot find documentation on how one associates a DX-released package with the Partner Community publishing console and LMA.

So It's worth playing around with DX for beta package releases, but released versions should still be published through the golden packaging org. That means going with the "Build and Release Your App with Managed Packages" flow in the DX guide instead. When it's time to release you still end up converting to Metadata API format and deploying to a packaging org. (Word to the wise: some things like Description and Post-Install Class can get clobbered when you do a force:mdapi:deploy so watch out to fix that on EVERY release.)

You still get a nice advantage out of DX: Create your packaging org, define a namespace, connect it to your Dev Hub and you can spin up scratch orgs with the same namespace as your package. It makes SUCH a helpful difference in development. Take a look also at the SFDX-Falcon template for some inspiration on how you can organize your project in DX. Even just the practice of having separate folders for unpackaged metadata that you use to help with testing but don't package into the app.

  • DX packages are not full packages like you're thinking of. They're used to create smaller packages inside your golden package, allowing you to create and update chunks of code that are more manageable. mdapi:deploy is not necessary if you're using DX packages, which is the point of DX packages.
    – sfdcfox
    May 23, 2018 at 4:45
  • Yes I know all that. But also, DX packaging for ISVs is still in beta and is missing some of the features that are part of the packaging org workflow. It should not be used right now for released managed packages. The current non-beta DX flow for managed packages does include force:mdapi:deploy.
    – Charles T
    May 23, 2018 at 11:32

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.