Tracking changes to CustomObjects
In Salesforce it's possible to enable history tracking on custom and standard objects. Once you've done this, you can then turn on history tracking on a per field basis, and so track changes to fields you're interested in.
Why deployments can fail due to changes in history tracking
In Gearset we break objects down into sub-components during the comparison, giving you control over which changes to an object you want to deploy. An example of this is standard objects and their fields. For example, you can deploy a new picklist value on a field without also deploying changes to the parent object to which it belongs, or changes to other fields in that object.
However, Salesforce enforces relationships between certain configuration options within these objects. The history tracking option is one example. If you tried to deploy a change to a field, such as adding a picklist value, and this change also turned on history tracking for that field, then your deployment would fail if the parent object in your target org didn't have history tracking enabled.
How Gearset solves the problem for you
We've added in a new feature to the underlying dependency analysis engine in Gearset so that we can detect when you're trying to make this type of change.
When this happens, Gearset will warn you and give you a chance to ignore the history tracking change on the field, but continue your deployment with all other changes to that field.
If you want to find out more about what the future holds for Gearset, check out our product roadmap.