Which metadata types should be tracked in your source repository ?
So your team has outgrown change sets and decided that it is time to leverage source control to power your Salesforce change and release management process. At this point, you might ask which types of metadata you should be storing in your git repository as the source of truth. If you are still looking for an answer, this blog is for you.
One of the questions we often heard was “aren’t we supposed to store everything in our source repositories ?” The answer is yes, for backup purpose, you should pull everything from your production instance and store in your git repository on a regular basis. This discussion isn’t about back up, however. This is about using git as the source of truth that sits in front of your production instance and drives changes going into production.
While it is possible to source control everything, for highly complex metadata types such as Profile, it is often more practical to keep these outside of source control. Let’s go through each group of metadata types and discuss their source control trade-offs.
Object metadata — recommended
Object metadata (fields, validation rules, custom buttons, …) is central to any Salesforce implementations. They drive business processes, page layouts and everything else in between. Therefore, it is vital that these metadata types are tracked in your source repository as the source of truth.
Code related metadata —recommended
Code related metadata (Apex classes, triggers, lightning components, visual force pages, …) are the cornerstone of any Salesforce orgs. A simple change in an Apex class could propagate changes to subsequent process flows as well as impact Apex test run and code coverage. It is therefore critical to track the above code related metadata types in your source repository.
Page layouts — optional
Page layouts are highly configurable, at the same time, less likely to impact business logic. We’ve worked with teams who opted to keep page layouts outside of source control and allow their admins to make page layout changes directly in their Salesforce orgs. Given the complex xml representing page layouts and the needs to configure them frequently as well as the low impact on business logic, source controlling page layouts can be considered as optional.
Permission sets — recommended
Unlike profile, permission set is a much better candidate to source control. The metadata xml representing permission sets is much smaller than profiles and it is also self contained. For this reason, Salesforce recommends teams to use permission sets instead of profiles whenever possible. If you use permission sets, you should definitely track this metadata in your source repository as the source of truth.
Process Builder — not recommended until after Winter 19'
Prior to Winter 19', a version number was appended to the flow name. This practice interfered with continuous integration and continuous deployment practices. For example, because each flow version had a different file name, orgs couldn’t track the flow’s changes in a version control system, which in turn could cause deployment problems. The good news is that Salesforce has recognized this problem and is making changes in Winter 19'.
Our recommendation is to keep process builder outside of source control and revisit after Winter 19'.
At ClickDeploy.io, we build recommendations and best practices right in our products, with the aim to make the entire process of setting up source control as effortless as possible. As you can see in the screen below, you can select metadata types to source control by type, group or complexity. For team beginning to adopt source control and CI/CD for the first time, we would recommend that you use the “source control complexity” filter and select all “Basic” types as a starting point.
