For those who have an existing MDAPI Managed Package and are migrating to SFDX.

I know we need to have a permanent MDAPI Org for the packaging (duh) but my question stems around SFDX and VCS.

Is my understanding correct? For this question assume I am willing to start a brand new repo using SFDX format but I do not think that affects the question..

I believe we need (i am probably wrong)

  1. MDAPI Permanent Org where the managed package is packaged
  2. (#1) Project in IDE for the MDAPI Org
  3. (#2) Project in IDE connected to VCS as the master branch
  4. (#3+) Project in IDE for each scratch org where development is done on the codebase

I am assuming for the scratch orgs where development is done that they will checkout a branch of the master. Once development is complete the PR and/or merge is performed.

Code is merged into master (#2) Project and committed to VCS. Yet another scratch org is created to deploy source, run all test, etc to confirm everything is working

Then a force:source:convert is performed and a force:mdapi:deploy is performed to push code into (#1) org which is the permanent packaging org.

The VCS is no longer associated with the (#1) Org/Project rather it is associated with the (#2) VCS org/Project

I must be missing something here and showing how deft I am but trying to wrap my head around this and seems like a lot can go wrong vs a single org development....And no, I do not have development with vcs experience outside of salesforce and I know it is showing lol.

1 Answer 1


The real power of SFDX is explored when we have some scripting solution to automate few things . Here is one of the approaches I have adopted

1.Every developer has there own branch that begins with dev.developername .We keep only SFDX format code here nothing else .Developers will always work with SFDX format only .

2.Have a staging environment where again we keep only SFDX format code.(Code is merged from various developers here) , however when code is merged here , we create scratch orgs run all tests and destroy the scratch org .

3.Master branch - This is the packaging org .Here we keep again SFDX format code , however there is also a folder or directory to keep the converted source from SFDX to metadata API on each push from staging.

4.Automate via a Continuous Integration to see if branches marked as master or with a flag that needs metadata API runs convert and deploy command to deploy the code to the respective orgs .These can be staging for testing or QA.

enter image description here

  • 1
    Thanks. This seems to confirm what I was thinking just more succinct and minus the need for a separate vcs org...
    – Eric
    Oct 15, 2017 at 4:01
  • Did you continue with your old repo or start a new one?
    – Eric
    Oct 15, 2017 at 4:06
  • New repository all together ! And the metadata API keep in the folder in the master branch .That folder can be path for override when convert happens . Oct 15, 2017 at 4:08
  • Sorry, "path for override" means a default path for the project source convert?
    – Eric
    Oct 15, 2017 at 4:10
  • 1
    yes thats correct ! Oct 15, 2017 at 4:11

You must log in to answer this question.

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