4

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.

3

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.

0

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 '18 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 '18 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.