6

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.

Improve this question

1 Answer 1

Reset to default
8

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

Improve this answer
8
  • 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 .
    – Mohith Shrivastava
    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 !
    – Mohith Shrivastava
    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 .