User Stories - Commit Files

Updated a month ago ​by Iván Minaya

Copado is shipped with a powerful Git Client, that’s built with Salesforce metadata in mind.

It’s really important to know how to properly commit files, because these committed files will drive the Deployments later on in the release process. It’s key to commit all that is needed to deliver your User Story, but without committing more than necessary.

When creating a new commit, the user will be prompted to enter a commit message and select metadata components from a list of items. The metadata list comes from the source Org that’s configured in a Git Snapshot.

When committing, Copado will create a package.xml on the fly and perform a Metadata retrieve of the selected metadata. Then Copado clones the repository/branch and updates the retrieved files in the branch. Finally, it will push the changes back to the repository.

Understanding how changes are committed requires a Key understanding on how metadata retrieve works, and also how Copado enhances it.

Here some examples of different metadata retrieve behaviours:

  1. Easy ones: 1:1 (1 metadata component = 1 file in Git)
    1. These are the majority of the metadata types, so there is no need to list them all. If a Metadata type is not listed in the Danger list below or in the Special cases, it should be an easy 1:1 type. 
    2. Examples of this category are:
      1. ApexClass, ApexTrigger, ApexPage, ApexComponent, StaticResource, etc.
      2. Report, EmailTemplate
  • Danger ones: 1*:1 (1 parent metadata component = 1 file in Git) but it will include many nested components
    • The best practice is to never commit a Danger metadata type (e.g. CustomObject), unless it’s newly created and it will be committed for the first time. Once this danger metadata type is committed, users should continue adding nested components to the parent Component.
    • A clear example is as follows: A developer or admin creates a new Custom Object, the user will commit the Custom Object for the first commit, this will include all fields and validation rules that the user setup at the moment of the first commit. After this point, the user must commit only the incremental changes, such as new fields, changes in validation rules, list views, fieldsets, etc.

Have this list in mind the next time you commit Danger metadata types in Copado:

Special Cases

  • Profile
    • When committing profiles, only User Permissions will be included in the profile unless other components are selected as well.
    • To deploy the Field Level Security of a field, for example, the user has to select the profile together with field in the same selection, same commit. The same applies for Tab visibilities, user has to include the CustomTab to get the visibility of that tab. Most typical metadata components update in a Profile are CustomObject, CustomField, CustomTab, Layout, RecordType, ApexClass, ApexPage, CustomApplication, CustomPermission, and HomePageLayout.
    • Copado will merge the retrieved permissions into the Profile in Git.
    • When committing files, if you select the "Retrieve Only" checkbox for custom objects, custom fields and page layouts, you will be able to pull OLS/FLS/Layout Assignment without having to commit/deploy the original field/object/layout files. Follow this link to get more information.
  • PermissionSet
    • Permission sets behave the same as Profiles, only permissions for other selected metadata components will be included.
    • Copado will merge the retrieved permissions into the Permission Set in Git.
    • You can select the “Retrieve Only” checkbox for custom objects and custom fields to pull OLS/FLS without having to commit/deploy the original field/object files. Follow this link to get more information.
  • Flow
    • Deploying a Process Builder Flow in Copado is a seamless process.You’re able to deploy a Flow that is active in the Source Org, and the Flow will be activated automatically in the Destination Org. You can commit an active flow to your repository, and deploy from the commit. Follow this link to get more information.
  • FlowDefinition
    • The FlowDefiition can only be deployed if the Flow already exist on destination. In order to make a deployment not repeatable, the recommendation is not to include this on the source control system (Git) by adding it to your .gitignore file.

How did we do?