User Stories - Commit Files

Updated 2 weeks 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:

Validate Commits

From the Commit Changes page,  now Copado allows performing a validation deployment before actually committing the changes into Git.  In order to have this functionality working the user must include in the commit message the following pattern: @validatecommit. This command will create the validation deployment without committing any change in the repository. If the deployment was successful, the commit is executed. 

The validation of a commit relays on a validation deployment in the target org with the selected metadata components selected on the commit changes action.

Some considerations when using this feature:

The validation is done in the target org with the Metadata retrieved from the source org.
The components that are validated are the ones selected in the commit.
The validation is made with the Metadata without being processed or merged in any branch.
When doing a validation  commit, no promotion or deployment records are created.

If the validation fails:
- The commit will not continue. Nothing will be merged in the feature branch.  If the feature branch doesn't exit, it won't be created.
- The validation errors will be displayed in a pop up in the commit page.
- A User Story Commit record will be created in the user story. The Snapshot Commit linked to that record will have the Status Pending and a blank value in the Commit Id field since nothing was committed.

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 exists in 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.

As of v11, Copado introduced new Git Operations, click here for more information.

How did we do?