How to utilize Devhub for Managed Package development?

Question

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.

Answer 1

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.

Answer 2

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.