Committing Incremental Changes in Copado
An incremental change is a small addition to an existing file. Copado offers you the option to commit just these additions rather than having to commit a full object that has been previously committed. Below we will describe several uses of incremental changes in more detail.
To show you how incremental changes work with nested components, let’s take as an example a custom object.
When you create a new custom object, the object will be committed for the first time. In this case, you should commit all the nested components, fields and validation rules that you set up at the moment of the first commit. However, for future additions, Copado allows you to commit just the incremental changes (additions) such as new fields, changes in validation rules, list views, etc. rather than having to commit again the entire object.
When doing this, Copado will only migrate the additions or changes of nested components included in the User Story selections, without impacting other nested components that are part of the object’s file, thus reducing the deployment time.
Profiles and Permission Sets
The most typical permission updates in a Profile and Permission Sets are access to or visibility of a CustomObject, CustomField, CustomTab, Layout, RecordType, ApexClass, ApexPage, CustomApplication and CustomPermission.
To set the level of access in a profile or permission set to a specific component, you must include in the same commit both the affected Profile/Permission Set and the component.
- If the related component does not exist in the destination environment, both Profile/Permission Set and component should be marked as Selected. If you flag the related component as Selected, the component will be committed and deployed.
- If you just want to update the permissions in the Profile/Permission Set and don’t want to migrate any work in progress in the related component, mark the Retrieve Only* checkbox when selecting the component.
*The Retrieve Only checkbox allows you to update a permission without committing or deploying the related component. The related component must exist in the destination environment, if it doesn’t, you will get a deployment error.
For a step-by-step process on how to commit changes, check out the article How to Commit Changes.