When using a git repo with a SFDX folder structure + package/xml (in the /manifest folder) gearset dos not take into account elements in the package.xml when checking the option (filter with package.xml)

In most of Tech industry deployment lifecycle, all code or config changes are ideally pushed into production only from a FullCopy Sandbox(Commonly Known as Staging Environment).

It would be very good to have a feature in GearSet App which if enabled shouldn't allow user deploying data from Dev/DevPro/Partial Sandbox into Production Org.

When metadata is retrieved from Salesforce the order of child nodes is not guaranteed and results in false-positive changes when committing to version control. Usually this will be something simple like workflow actions/criteria appearing out-of-order which can be compared manually. However, recently we've noticed entire profiles being committed with *every* permissions element out-of-order, resulting in a change set with ~20k lines where the *actual* change is impossible to visualize.

Gearset should provide a feature to 'order' child XML elements alphabetically by name in order to provide consistent commits to version control and eliminate false-positives.

As of now, if you have deletions enabled in a CI job, everything is deleted. It would be great to be able to specify which metadata types you want to include in the deletions since normally you won't need to delete all differences. This would be specially helpful to remove Apex classes and its permissions from profiles.

create an option to have chained deployments so complex deployments can be broken down and sequentially deployed or slaves can be ran

allowing for multi staged deployments under one CI job

ideally... gearset should not be hitting https://adlm.nielsen.com/bitbucket/rest/api/1.0/repos
first. It should hit https://adlm.nielsen.com/bitbucket/rest/api/1.0/projects to get a list of projects
then allow the end user to select the project
then https://adlm.nielsen.com/bitbucket/rest/api/1.0/projects/{projectKey}/repos to get a list of repos on the project the end user selects

In order to make deployments more repeatable between orgs please allow a way to save the selection of deployment analysis suggestions an d list of test classes with a package. With a large package it can be difficult having to document or remember the same selections used in deployment to UAT org for Production deployment.

Allow user to directly create a change set without doing the comparison. If user has a list of items that needs to be migrated then allow the user to add items and skip comparison step.

Better error reporting when CI jobs fail. Many times I open a failed job and there are no errors reported.

Show live the components deployed during the running of a CI/CD Job.

Like:
deploying class abc.......
deploying class xyz.......
deploying lightning Component abc.......

We have CI jobs that fire on commits to a source control repository. At the moment, there is no way to email the specific individual who made the commit that prompted the deployment, so we have to notify everyone involved in the project whenever a deployment fails. If we could just notify the individual who made the commit (plus the deployment manager), it would reduce noise considerably.

Please add this feature.

Currently, clicking Refresh Comparison does not optimize the comparison in any way, it just allows you to skip selecting some of the configuration steps from running a new comparison.

This means that it takes the same amount of time actually comparing the orgs.

It would be nice if on clicking of "refresh comparison" the logic didn't run a full compare and instead just looked at metadata that had been changed since the last compare in order to reduce the comparison time.

It's not convenient when a validation fails, to then download the excel file of the the validation errors, view in separately form Gearset, and then go through the list of metadata I'm trying to deploy and try to uncheck each one that failed the validation. It would be nice if Gearset did that for me.

I've enjoyed using the view on github or create pull request options when my target is a github repo. However, when I use the custom git repository option which still points to my same github repo but doesn't require me to wait for all of my repo's to populate in the list, I'm no longer able to use them after a successful deploy. Please add "View on GitHub" and "Create Pull Request" options when the target is Custom Git Repository.

I want to send the automatic report generated at the end of the deployment to my client. However, I want to personalize it with the logo of my company or add additional text.

Being able to configure which problem analyser results to use in CI jobs.

For instance, we can’t deploy any changes to managed packages because the problem analyser will ignore them (even though we have components from a managed package that we can modify and deploy without issues), that would help to reduce our manual steps during deployments.