1

I'm starting development of a lightning component that will extend functionality of a third party app used in our Production. The 'app' is composed of a dozen or so interdependent managed packages, and is really a full fledged suite built on the SF platform, similar to Sales Cloud or Service Cloud. The component I'm building will be using some of the third party app's custom objects and code/workflows (which aren't readable/editable, but which I will trigger via dml statements).

Another complication is that the part of the app that I'm working with relies on record-based settings instead of straight metadata. Since we have a full copy sandbox available, I can easily mirror the production org settings... but that would not be so easy in a scratch org, I imagine.

I have limited experience with SFDX, and have so far used it for standalone projects which only use homemade custom objects that are easy to pull and push between sandbox/production and the scratch org.

Is it worth attempting to use a scratch org and the full SFDX dev paradigm for this kind of project? I'm concerned about the complexity of dependencies between the many managed packages that make up this 3rd party app.

Is there any reason why I shouldn't attempt to use an SFDX project + CLI + VS Code, but use my Full Copy Sandbox as the destination org for pushing/pulling/testing project components?

Improve this question

1 Answer 1

Reset to default
1

Its important to understand that in salesforce DX the pull and push commands work with only scratch orgs and not sandboxes .

For sandbox you should be able to use mdapi commands to retrive and deploy.

For your use case, i see the advantages of using sandboxes and recommend to use that instead of the scratch org since you may end up doing lot of scripting with DX .

You can also try using the pre release CLI commands to make your life simpler

You will need sfdx client pre release plugin installed to try .

The commands are

sfdx force:source:retrieve -- retrieves metadata from the org using package.xml or metadata folder or comma separated list of metadata

sfdx force:source:deploy -- deploy metadata to the non scratch org To get started follow the instructions here

Install the Pre-Release Version of the CLI

sfdx plugins:install salesforcedx@pre-release Make sure that you have the pre-release version.

sfdx plugins --core

salesforcedx 44.0.1-xx

When the plugin is officially released v44 in mid October 2018, uninstall the pre-release version, then run the update command.

sfdx plugins:uninstall salesforcedx

sfdx update

Improve this answer
7
  • Thanks Mohith, I see the new force:source commands are referenced here: releasenotes.docs.salesforce.com/en-us/winter19/release-notes/… ... I've installed the pre-release and I will take a shot at this. Looks like the plan will be to use a hybrid of SFDX functionality and the traditional package deployment method.
    – smohyee
    Sep 13, 2018 at 21:25
  • 1
    That's correct !!! Leverage sfdx for your ci script and non scratch orgs
    – Mohith Shrivastava
    Sep 13, 2018 at 21:27
  • 1
    Yes it could be due to it .Why would you have to connect to PROD ? I believe you can connect to sandbox .Also these commands are in early stage so you can uninstall pre release and just use mdapi commands
    – Mohith Shrivastava
    Sep 14, 2018 at 14:38
  • 1
    These do more than mdapi commands ,they can retrieve and deploy by just using the path and don't need package.xml
    – Mohith Shrivastava
    Sep 14, 2018 at 15:01
  • 1
    Just tried using force:source:deploy on my sfdx project and you're right, no need to package up the source. Nifty!
    – smohyee
    Sep 14, 2018 at 15:14

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.