The "repository sanitizer" performs unsolicited/silently changes which confuse users and generate issues. For instance, if you have Apex class permissions in profiles for classes which are part of a managed package and are not present in the repository, this sanitizer will modify the permissions to false which is obviously a disaster, (and the changes can happen any moment, while users are trying to deploy something completely unrelated hence the confusion).

We know the solution is to have the classes also in the repository but for managed packages that's unnecessary extra work since then we need to be updating them every time the package is upgraded.

On the "Deployment Summary Page" it would be great to add a column to the list of metadata components added which shows for the "No Difference" items showing the source piece(s) of metadata which is causing this "No Difference" to be included.

This would dramatically help in the narrowing down of why a piece of metadata is included - especially if that piece of "No Difference" is a managed package and cannot be altered. In a large deployment, trying to identify a root cause for why a component was added is quite difficult. Simply giving a way to track back the cause will definitely help speed up the process of getting the package ready to deploy.

The problem analysis comes up with a number of Suggested Fixes which may make sense for improving Salesforce deployments, but which are unproductive when applied to git deployments.

For example, the suggestion to remove TASK.WHAT_NAME, or to omit Standard Objects, will only serve to create a git repo which is an inaccurate reflection of the source org. Each time we deploy to that git repo, we will continue to have the same changes to select or omit, since the repo is missing objects and fields from the source org.

When the deployment target is a git repo, all suggested fixes which remove fields and metadata in accordance with Salesforce best practices should be hidden/suppressed/omitted. Suggested fixes which add necessary dependencies to the deployment should still be displayed.

Sometimes during a complicated deployment I need to try a few different strategies to get things to work. For example, I may need to just send up one piece or set of metadata up first.

The problem is, each time I do this, I have to wait for problem analysis to complete, which takes a couple minutes. Normally during a deployment I do want problem analysis to run, but if I want to quickly send up a single object, I have to wait a few minutes while Problem Analysis runs, and the time waiting adds up.

Maybe a quick deployment option from the compare screen, where i could select my tests and either validate or deploy what's currently checked?

Thanks!

Turns out the following can't be done:

Change the type of a xxx__mdt.Foo__c (e.g. from Number to Text)

While the Force.com UI doesn't let you do this directly, you can do indirectly by deleting the Foo__c, then adding it back with a new field type. Your sandbox is a-ok with this

But if you try to deploy, SFDC won't let you deploy and you get this error: "This field is on an object that doesn’t support field type conversion."

Gearset Analyzer could check this by comparing source to target and give you a nice warning. Would save the developer/release manager a painful correction once this gets into source control

We've found when developing classes against managed packages the class ...meta.xml includes the package version numbers. Problem is these are fixed to the exact version installed (e.g. 9.4, 9.3 etc. example below)

But then if the managed package is upgraded Salesforce, in its infinite wisdom, doesn't update these so when you come to deploy next time you have to go and manually update all the version numbers - or if you have a different version in another sandbox (to test the newer one) same thing.

Seems like something a cool deployment tool could handle and offer to fix up on deployment.

<ApexClass xmlns="http://soap.sforce.com/2006/04/metadata">
<apiVersion>41.0</apiVersion>
<packageVersions>
<majorNumber>9</majorNumber>
<minorNumber>4</minorNumber>
<namespace>foo</namespace>
</packageVersions>
<status>Active</status>
</ApexClass>

While comparing two Org's for differences and saving the 'Draft deployment':

1. Files that I'm sure and fine with the differences and happy - so tick them.

2. Files that are important to be deployed but I am yet to discuss those differences with some peers from team (dev / support). I would like to mark these (or / and) comment against these - with some useful notes (ex: impact or risk analysis related notes). Once these are discussed, I can then tick them - indicating I am happy to deploy these.

Once I mark the files as either 1 or 2 above, then I would like to save my Draft deployment

To me, it would be nice to have feature !

Thanks
Savarni