-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Moving source between the local project and the org via the Salesforce CLI #1
Comments
Should mdapi:deploy and mdapi:retrieve default to the source format rather than the mdapi format? AFAIK the underlying Metadata API is still working on the original mdapi format. I'd use that as a case for the default behavior to be mdapi format. Then the source format, which doesn't match what the mdapi is doing on the wire, could be the optional behavior. What will happen to any selectivity options that applied to source:deploy/retrieve that don't make sense to the direct mdapi? |
I second Daniel's comment here! |
I think it's ideal to be able to just work with sfdx folder structure and then control pushing it to/from scratch orgs, or to/from sandboxes/production. It's also ideal to not have to worry about accidentally pushing to prod, so the different commands for each are ideal. Also ideal to be able to just retrieve from Prod straight into source folder (sfdx) and trying pushing to a scratch org to quickly get into the sfdx flow. A big issue for adoption for consulting is easily making the switch, so anything around that is delaying a lot of devs it seems. We only use it for ISV projects and not consulting. As with any big procedural change like this, it would be fantastic to have a flow chart of how to use sfdx cli to deploy/retrieve and push/pull to make it easy to transition. The video in the Falcon Template is very helpful to understand how the internal team envisions the folder structure, and workflow. Also the old Force-CLI has more flexibility for things like selective deploy/retrieve it seems. it would be nice to easily only deploy some things. On the Consulting side we can't always do a 100% deploy of source from git, and may not want to, so tools like Gearset come in handy to handpick items to deploy. |
+1 to @JimBTek What will happen if we need to use both flavors (package.xml and DevHub tracked source) of deploy/retrieve in a project? Will it be easy to differentiate between them? Also, please ensure that no DevHub will be required for package.xml-based deploy/retrieve. We have a project in which the client will not turn on DevHub because their approach to security is that absolutely no one should have any special access rights to production, so we are completely missing out on being able to track changes in metadata. |
I like the naming being clear. Commands with "mdapi" manipulates metadata api format, while commands with "source" manipulates source format. So instead of deprecating source:deploy/retrieve, why not deprecating mdapi:deploy/retrieve instead, as source format will be the default ? Command would do the same, I'm just talking about the command name here. Also, why moving convert under project ? From time to time I convert from mdapi to source and never understood why this command requires a project. I also find that "project:import" is not really helping to know what it's really doing, compared to mdapi:convert which is a pretty obvious name. |
@FabienTaillon is indirectly scratching an itch that I have had for a while regarding the naming of The convention in Salesforce CLI is to have nouns in all the components of the command except for the last one. Thus, |
I'd really like the ability to use the .forceignore file with just push/pull and have a separate one that works with convert/deploy - specifically around working with Gen 1 packages. The use case here is that I often want files like permission sets or non packaged code to be part of my push/pull, but do not want that to be part of the convert/deploy process since they aren't part of the package. Right now, I don't know of a way to do that and as far as I know it isn't possible? |
I personally think Additionally, I am completely against renaming the mdapi commands, as it would be a breaking change that could possibly break CI. |
@britishboyindc Agreed. the Falcon Template has some scripting for things like that and places in the folder structure for code that is for testing only. the video is helpful. not sure it does exactly what you want, and would be nice to not need a template with scripts to achieve it |
+1 to @gdoenlen If I am understanding the proposal correctly, I agree with these changes since it will enforce having just one set of commands to Personally, I agree with the renaming proposal to under I envision at the end the |
@gdoenlen There's a feature in OCLIF that allows you to create aliases of commands. You could probably provide backwards compatibility without breaking a sweat. |
@catalandres breaking changes are still breaking changes and they shouldn't be taken lightly. "Never break user space." |
I like the proposals from @clairebianchi.
|
I am 100% in favor of bifurcating commands intended to work with source-tracked environments (scratch orgs) and production / sandbox envs. Having additional selectivity on the Additionally in favor of standardizing to one source format - Finally, BIG WIN bringing the |
Current behavior of I agree with @gdoenlen, the I like @abd3's suggestion for adding a new |
@clairebianchi - These are interesting proposals. I'm glad you've started this dialogue with the community. Lots of great comments and suggestions so far, too. It's heartening to see the passion that goes with this toolset. :-) Here's what I like and what I wish might (and might not) happen. Two Command Sets To Rule Them All: GREAT IDEA! Source Push/Pull Work Against Any Org: PLEASE DO!
"Source" commands mean I'm dealing with the new decomposed metadata format on disk. Don't make me care too much about how it gets into the target org. Keep Metadata API deploy/retrieve are well-known, battle-tested ways of moving Salesforce metadata. Having it work only in a way that's familiar to the ANT Migration Tool makes it that much easier to convice old-school holdouts to dip their toe in the SFDX waters by moving to the Salesforce CLI. Moving I agree that it could be useful to have some sort of Add greater selectivity options to all the "metadata movement" commands: LOVE THIS! |
@clairebianchi Thank you for starting GItHub dialog with the community on these changes, some nice ideas are on this thread. Here is my idea: mdapi:retrieve - seem to only pull from DEV. Sandboxes in old metadata format. We will need a convert from metadata to SFDX format. I think making SFDX CLI workflow more unified will help developers. That conversion of source format step may be done by VSCode plugins. |
Thank you all for the feedback. I am working on revising the project based on your guidance and will post our final plan here in a few days. |
What's the issue with source:deploy/retrieve ? They've finally allowed me to fully embrace the new source format for my existing projects where I can only work with sandboxes. If they are "merged" with the existing mdapi commands I assume the functionality will stay the same? I agree with others, it would also be a bit strange and confusing using mdapi commands against the source format. Personally, I'm fairly happy with source:deploy/retrieve as they are, it's clear they intended for deploying/retrieving the source format to/from sandboxes. For scratch orgs we have source:push/pull which doesn't require specifying components/manifest/etc. The mdapi:deploy/retrieve commands still have their place i.e. working purely with the metadata format. This is still needed because many people will still have projects in the metadata format in version control which can't easily be migrated due to complexity, active development etc. |
Just shouting out that I love this. |
Any update on this? |
Since the confusion seems to be that 'source' can be both interpreted as 'source data structure' and 'source-tracked method of moving data between the local and org', why not make it explicit that the middle part is a NOUN and about the data structure, and the last is a verb and about the method of moving data. (also see @catalandres 's itch :)) You could for example replace the middle one with 'sourcedata' and 'mdapidata', giving you: force:sourcedata:push force:mdapidata:deploy ...and then what happens in the recent 'magic mix' between the 2 becomes more intuitive: or maybe 'files' is even more clear and explicit than 'data': force:sourcefiles:push force:mdapifiles:deploy ...and then what happens in the recent 'magic mix' between the 2 becomes more intuitive: Or, MY FAVORITE, because instead of 'data' or 'files', actually 'source' is actually the best noun here for what's being pushed/deployed: how about 'source' vs 'mdapisource'? So is 'source' the short and sweet default, but there's another 'legacy' style source which is mdapisource. Both can be old-fashioned deployed and retrieved, (force:source:deploy and force:mdapisource:deploy), but only 'regular' source can be pulled/pushed the modern way. |
As an additional thought to my previous comment, you would want to start referring to what you now call 'source format' in a new way, like 'tracking-friendly format' something. Then you can explain things as follows: 'A new sfdx project will by default have its source code and metadata arranged in a modern, tracking-friendly format. You can push/pull between this local source and a scratch org with force:source:push / force:source:pull. To more drastically deploy/retrieve source in this format, in the old non-tracked way, for example against a developer org, you can also use force:source:deploy and force:source:retrieve. For the older formatting of source code and metadata, called metadata api format or 'mdapi format', you cannot pull or push but you - can - deploy and retrieve, with mdapisource:deploy and mdapisource:retrieve.' How neat is that? Minimal syntax change, current force:source commands can stay as is, and super intuitive what you are actually doing in the 'old' style with force:mdapisource:deploy / force:mdapisource:retrieve |
The Salesforce CLI team launched the source:deploy and source:retrieve commands in Beta in winter 19. After collecting your feedback we have realized that the overlap between the mdapi and source deploy and retrieve commands is causing confusion about what commands should be used with which workflow (org development or package development). Due to this feedback, we are proposing the following changes:
The Proposal
Overall:
There will only be 2 sets of commands that move source to and from orgs:
source:push, source:pull - these commands will track changes between the local project and the org
mdapi:deploy, mdapi:retrieve - these commands will allow for fine-grained or bulk manipulation of source
Both sets of commands will default to maintaining the source file folder layout (i.e. source format), with an option to override the default for deploy and retrieve if you want to work in the older project file format (i.e. mdapi format).
Push and pull will work in source tracked orgs, and deploy and retrieve in all orgs
Other changes:
We are going to add the additional selectivity options to mdapi:deploy/retrieve that are currently available on source:deploy/retrieve and then deprecate source:deploy/retrieve.
mdapi:convert will be moved under the force:project topic and likely renamed to project:import. We will also add the additional selectivity options available for source:deploy/retrieve.
source:convert will be moved under the force:project topic and likely renamed to project:export. We will also add the additional selectivity options available for source:deploy/retrieve.
The mdapi:delete command with selectivity options will be implemented.
The text was updated successfully, but these errors were encountered: