This document looks to provide guidance around which metadata types to include when setting up Gearset Pipelines for the first time. Ultimately we'd like your pipeline to be as successful, high functioning and low maintenance as possible. That's what this guide hopes to ensure.
Generally speaking, when setting up a git repository for the first time, the advice is to only include metadata types that you're likely to touch. However, even for an experienced developer, it can be really difficult to know up front which types you do and don't touch as a team. Salesforce metadata is inherently complex and heavily interconnected, so there could be dependencies between different types that you're understandably not aware of.
Our advice
What to include
We would recommend that you keep the metadata filter as wide and all encompassing as possible. It's perfectly reasonable to include almost all metadata types, just to be on the safe side. Even if you don't touch a particular type today, who's to say that you won't in the future. So as a starting point, you can:
Use the
Compare alloption to preselect everything.Set the
Include managed packagesoption toAll.
Then you can work down from there, making certain exclusions. Our continued advice on these is as follows.
What to exclude
As with anything, there are a few key exceptions that we'd advice against including as they might introduce problems down the line. As follows:
Installed package - You're safe to include all managed package metadata, but this metadata type is only really needed if you're specifically looking to update the version of managed packages via the Pipeline. This metadata type has been know to introduce problems if your package versions aren't perfectly in sync between environments.
Site.com - This is a binary file and the checksum changes frequently, and so a comparison of the same file at two different times often shows as different. Essentially, these files will never be in sync, so are best avoided.
Static Resource - You may not need to exclude all of these, but some of them contain 'Binary: Resource data (MD5)' which is constantly changing and Salesforce can automatically opt to include it in any package that they validate.
Types that are frequently customized directly in Production - Here is suggested list of types that often are edited directly in Production, and so these are at risk of being overwritten as part of a pipeline deployment. If you are familiar with doing the same to one of these types, consider removing it:
Report
Dashboard
ListView (A sub-component of Custom object).
Auth. provider
Certificate
CSP trusted site
Named credentials
SAML SSO config
Anything else - There is no "one size fits all" advice for all customers. There may be particular metadata types that you know you don't want tracked, types that you want to manage outside of the pipeline (similar to our Reports and Dashboards example), in which case, you should remove them from the filter.
When you're done
Once you've configured the filter you'd like to use, in the top right of the window, select the dropdown arrow and select Save as new filter. Give your new filter a recognizable name and click Save as. You'll now have access to this saved filter, for use both when initially seeding your repository and configuring your automated jobs.
Additional questions
Are there any downsides to having such an all encompassing filter?
It's considered general best practice to avoid putting metadata types into your repository, that'll never be modified or touched by your development team. This is purely done with the goal of not cluttering up your repository. If you're not concerned about "clutter", and would rather play it safe, there are no further downsides to being more all encompassing with your selection. In our experience, the benefits of including as much as possible heavily outweigh the negatives of cluttering your repository.
Should we source control ALL metadata types, including those exclusion examples?
If your goal is to simply backup all metadata from an org, then you could consider doing absolutely everything. But in this document, we're specifically talking about configuring your repository/filter to work with Gearset Pipelines. Making some active exclusions is perfectly fine.