Org Browser

This proposal is for a solution to deploying and retrieving metadata to non-scratch orgs that limits the required use of the package.xml file. The goal of this proposal is to simplify the dev lifecycle for developers that work directly against orgs, but don’t want the complexity of crafting package.xml manifests every time they want to do some work.

This proposal introduces the concept of a Working Set (Name TBD). A Working Set is a group of metadata types or items that can be deployed or retrieved together. A working set can be exported to a package.xml file. A working set is only a concept in VS Code - it is not something that is implemented on the actual Metadata API.

Working Sets are purely temporary groups of metadata that are used to perform various tasks in VS Code - while they will persist across sessions of VS Code (mostly to avoid losing work if you accidentally close VS Code) they cannot be checked into source, nor are they designed to do production or scriptable deployments like changesets or package deployments are. The most basic case for using working sets is when developer using VS Code wants to work on a few different files at the same time and quickly deploy them to their development org to see the changes. Fundamentally, working sets are primarily just UI to expose the CLI command sfdx force:source:deploy --metadata <metata types/instance> and sfdx force:source:retrieve --metadata <metadata types/instances>. Working sets are also the way you can build apackage.xml file in VS Code. You can add items to the in-memory working set and then export them to a package.xml manifest file. In the future, this UI could be used to edit/import existing package.xml files or we could even imagine this UI being extended to help build changesets, but those features are not in the scope of this proposal now.

It is also worth noting that this UI only supports non-source tracked orgs. It does not work against scratch orgs as source tracking deployments do not currently support fine-grained push or pull. If in the future, source tracked deployments support the ability to push/pull a specific set of source to/from an org this UI will be adapted to support that functionality. This would be analogous to the hypothetical sfdx force:source:push --metadata <metadata types/instances> and sfdx force:source:pull --metadata <metadata types/instances> commands.

The UI would introduce a new tab in VS Code called the “Org Browser”. The org browser would show the currently selected org and the metadata. Switching orgs would be done via the Org Picker UI (see #623).

The Org Browser would show all metadata in the org as well as a button to refresh the view with the current state of the org and a search filter. Note, the search filter is currently not possible as a result of VS Code’s extensibility, but will be provided for all tree views in a release very soon.

Metadata types and instances could be right-clicked to bring up an action menu. This action menu would have four functions:

• Copy Name - Simply copies the name of the metadata class or item.
• Retrieve Source from Org - Retrieves the metadata from the org to the default directory. If the metadata already exists locally it would be overwritten.
• Deploy Source to Org - Deploys the local copy of the metadata to the org, if their is no local copy of this metadata this item would be disabled.
• Add/Remove to Working Set - Adds (or removes if already in the working set) the metadata or metadata type to the current working set.

IMPLIMENTATION NOTE: Not all metadata types can be included in a package.xml using the wildcard * notation so not every metadata type will be able to be added to a working set. In those cases only the individual metadata of that particular type will be able to be added to the working set. See: https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_types_list.htm

The pane below the metadata tree shows the items that are currently in the working set. These items can be removed by right-clicking and selecting “Remove from Working Set”.

The working set pane contains three buttons:

• Save/Export - This button exports the current working set to a package.xml file. The user will be prompted for a name and location to save this file.
• Deploy Working Set - Deploys all the items in this working set to the currently selected org.
• Retrieve Working Set - Retrieves all the items in this working set from the currently selected org.

In addition to the menus, there would also be two commands in the VS Code command palette.

• SFDX: Deploy Current Working Set to Org - Deploys the items in the current working set to the org.
• SFDX: Retrieve Current Working Set from Org - Retrieves the items in the current working set from the org.

Lastly, files in the regular explorer tab could be added to the working set as well via the right click menu.

[JodieM]

OK, so I like the concept, but not sure about a few specifics. For me the almost ideal package.xml builder is what was in MavensMate, even though it was really slow and cumbersome, but that was more to do with the Metadata API being slow on large orgs.

Refresh the Org Browser is great, thanks.

Search Filter would be great, but I understand that it’s not something you can do now.

Add files from Explorer is an nice option, thanks.

Can I have multiple Working Sets on the org at the same time? It seems so from your mockup, but I’m not sure. But that would be cool - eg I’m working on code, but I need to just quickly deploy some field and layout changes - it would be good to have those separated.

I would want the option to Add All Metadata to Working Set, so I can do a backup of the Org.

I would want to be able to Import a Working Set - eg I have a standard list of things I work on from one org to the next - for me that’s all Object stuff, all workflows, flows, process builders, all Email Templates, etc - all the main declarative stuff. Similar to the “all the code” default package.xml you include now but for declarative side of things.

Or Default Working Sets - Illuminated Cloud has two sets of metadata to choose from, just to make the metadata list be not so overwhelming. The Welkin Suite has an Admin mode and a Developer Mode. Something like that would be a good starting point, especially for Admins who don’t want to look at the code. But I do understand your priority is making VS Code work for developers first.

With Retrieve Source from Org, please make it not overwrite if you have not deployed yet - MavensMate did that and it could be quite dangerous if you havent committed or deployed (but hopefully you’d have the changes in your local git anyway).

Absolutely need the ability to retreive metadata within a Working Set then deploy that Working Set to another Org, as @ChuckJonas said.

Absolutely need the ability to create a Metadata file and add that to a selected Working Set. @gbreavin mentioned Code, but I would often create brand new Reports, or brand new Layouts or brand new Email Templates via MavensMate. You can NOT do this at all in The Welkin Suite and it’s one of it’s huge limitations.

Can you still Deploy single Metadata files at a time. I think this is now possible with Deploy on Save? That might be good enough to work around the adding new Metadata if that’s not possible.

Yes another +1 for Compare with Org as mentioned by @ChuckJonas but not entirely sure how that would work in practice. It’s probably something that could be done with a diff extension anyway.

It’s really imperative that anything you do handles Managed Packages really well. MavensMate had an option to include or exclude Managed Packages. Unfortunately the way The Welkin Suite handles managed packages is not OK at all, and they don’t seem to retrieve customisations to Managed Packages at all (eg if I build a Process Builder on a Managed Package object) (but hopefully that has changed since I last looked). If you are mainly dealing with wildcards then it seems though it would include Managed Package items also.

Whilst Wildcards are OK, I would still like to have the option to Select Individual Metadata Items from the org, just like MavensMate allowed. But that could be an enhancement for later. I’ve just dealt with large orgs - say that have FinancialForce installed, and just downloading the Reports metadata fails completely becuase there are too many reports. I really don’t want to download any FF reports.

Will the Org Browser work with large orgs - yep, I’ve had MavensMate fail to retrieve just the fulll Metadata list from a large org, let alone the Metadata itself.

If I can have Working Sets in any way shape or form mean that I don’t have to deal with Change Sets anymore, I will be ALL over it! Thank you!

[ntotten]

As an alternative UI, it might be nice to do something like the Git ui has for selecting files to add to staged changes. I am not sure if that type of UI can be built though with the treeview. But it may be nice to have both the metadata and selected items in the same VS Code pane. Something to consider when we are investigating UI.