Copado‎ > ‎

Adding Steps to a deployment

Deployments are carried out in various Steps. The Copado package includes the following Step types: MetaData, Delete Metadata, Full Profiles, Full Permission Sets, Users, Translations, Custom Settings, Data, Bulk Data, Apex, Manual Tasks, Git Metadata, Quick Actions.

Metadata Step

Deployment of Metadata components. For a complete list of deployable metadata components please refer to the Salesforce Metadata API documentation.
Selected metadata components will be retrieved from the Source Org and then deployed to the Destination Org. 


Check Only
option will not deploy the changes, it will be a Validation only deployment.

Test Level deploy options

  • No Test Run (not apex test are run unless is a production deployment)
  • Run Specified Tests (only included apex test classes will run, aka Fast Deploy)
  • Run Local Tests (all apex test classes excluding managed packages)
  • Run All Tests In Org (all apex test classes including managed packages)
More information regarding Test Levels

Find and Replace in files (available since Copado v3.11) allows users to find a specific text inside the Metadata files using a Regular Expression for matching, and replacing matching pieces with a given text. Use cases for this feature are countless, but here are just a few examples:

  • Deploy Outbound messages are now possible! by replacing the "Run as" username with the right username on the destination org. Find regex: 
    user@server\.com\.dev
     Replace with: 
    user2@server.com.uat

  • Deactivate workflow rules: Find regex: 
    <active>true</active>
     Replace with: 
    <active>false</active>

  • Remove Weblinks from Page layouts: Find regex:  
    <customLink>[.\S]*</customLink>
      Replace with: 
        
  • Skip a specific user Permission (typically needed when deploying between to different salesforce releases). Find regex: 
  • (?m)(?s)<userPermission>[\s\S]*?<name>DelegatedTwoFactor</name>[\s\S]*?</userPermission>
     Replace with: 
        
     Note: change 
    DelegatedTwoFactor with the permission name to replace
  • Skip a field from a layout, typically needed the field doesn't exist on destination. Find regex: 
    (?s)(<layoutItems>(?:(?!<layoutItems>).)*?<field>Account_Executive__c</field>(?:(?!<layoutItems>).)*?</layoutItems>)
    Replace with: 
        
    Note: change 
    Account_Executive__c with the field name to replace

Find and Replace


Full Profiles

Deployment of Profiles using the Metadata API. During deployment, profiles are automatically cleaned, removing any components that do not exist in the destination Org (by retrying), and preventing the deployment to fail. The engine retries until it either gets a successful deployment or gives up after 100 retries.

Some limitations are imposed by the API, for example Tab settings are not deployable. For details, please review the Metadata API documentation. “Full” Profiles are called like that because we do a full describe of your org, to make sure we included every single property of the profile. Basic profile deployments can be done using a Metadata Step, and profile's properties deployed will be relative to the set of metadata included in the same step.

Full Permission Set

Just like with full profiles; Copado will deploy every single permission setting within the Permission Set. The Permission Set is then automatically cleaned to remove permission settings that cannot be deployed (e.g. due to destination Org differences) and then the deployment is re-initiated. The result is that every single deployable security setting within the Permission Set is deployed.

Users

A brief demo of how to deploy users using Copado Deployer

Deployment of Users and optionally User Territory assignments and Permission Sets. For users with a manager and/or delegated approver assignments, these are mapped across too. Both standard and custom fields of users are deployed in a User step. Only internal users (UserType=’Standard’) will be retrieved.

Territories and Permission Sets

When transferring territories and/or Permission Sets, these need to have been deployed already in a previous step in order for the user step deployment to succeed. Copado will deploy users and automatically and then associate the corresponding Territories and/or Permission Sets with the User.  If the users are not activated Permission sets won't be able assigned.

Manager and Delegate Approver

When transferring users with an associated Manager and/or Delegated Approver, Copado will deploy the users and associate the Manager and/or Delegated Approver with the deployed user automatically. Please note that the related User must also be queried and be present in the deployment. This may all be done within 1 step and does not require a multi-step deployment as with Territories and Permission Sets. In order for Permission Sets to be assigned the users must be deployed as ‘Active’.

Suffix information

During the deployment Copado will append a suffix to the Username, email and the Community nickname. If no suffix is specified nothing will be appended. If a ‘From Suffix’ is specified and not a ‘To Suffix’ then the text ending with the ‘From Suffix’ will be replaced with the ‘To Suffix’.

E.g. a deployment from sandbox called, "UAT" to Production The From Suffix will be set to "UAT" and the ‘To Suffix’ will be left blank. John Smiths username (e.g. Jsmith@company.com.uat will become Jsmith@company.com. Bear in mind that User deployments must run on a single destination Org deployment.

Example Sandbox named, ‘UAT’ -> Production
Email jsmith@company.com.UAT -> jsmith@company.com
Username jsmith@company.com.UAT -> jsmith@company.com
CommunityNickname JohnSmithUAT -> JohnSmith

 

Translations

Deployment of full language translations. Selecting a language to be deployed will deploy all translated values for that language for all Salesforce components (not just those included in the deployment). Every single translatable piece that is translated will be deployed (including everything in the Translation Workbench and all that are NOT part of it as well, like labels, tabs, object names, etc).

Data

Deployment of records using always the Upsert call of the SOAP API. Data transformation is currently not supported. Batch size: 200. The app is expecting the same fields at the destination (API names and data types). Remember that the Data step allows related records (relationships) to be migrated, eg:

Step 1: SELECT External_Id__c, Name from Account

Step 2: SELECT External_Id__c, Lastname, Account.External_Id__c from Contact

Step 3: SELECT External_Id__c, Date__c, Number__c, Account__r.External_Id__c, Billing_Contact__r.External_Id__c from Invoice__c

Step 4: SELECT External_Id__c, Quantity__c, Unit_Price__c, Invoice__r.External_Id__c from Invoice_Item__c

Changing the batch size: Is possible to change the default batch size (200 records) by adding the following text on the Step name ":batch=N" where N is greater than 0 and less then 200. Here is a step name as an example where the batch size is set to 20: "Accounts :batch=20"

Bulk Data

Deployment of records using the Bulk API. Batch size: 1000. Data transformation is currently not supported. The app is expecting the same fields at the destination (API names and data types). Remember that the Bulk Data step does NOT allow related records. This is a Bulk API limitation rather than a Copado limitation.

Delete Metadata

This step allows you to delete Metadata components in your Destination Org. The list of available components displayed is taken from the Source Org which you would like to delete in the Destination Org.

Custom Settings

The Custom Settings step allows users to deploy the data held in Custom Settings objects. IDs such as that of Users, Profiles and the Organisation Id for Hierarchy Custom Settings are also mapped in the destination environment.

Apex

This step allows users to execute Apex Anonymous scripts as part of a deployment in the destination environment. A frequent usage scenario is the un-scheduling of scheduled Apex jobs prior to deploying an Apex class. The Apex step can then be used to reschedule the newly modified Apex class. Another use-case is a sandbox initialization where the creation/modification of data can be achieved via Apex post sandbox refresh

Git Metadata

This deployment step may be used to Deploy contents from a Git Commit as well as information included in a repository that was not in a selected commit.  In such an instance the Git Repository will retrieve the latest version of that file within the repository. It's also possible to create a deployment directly from a Git Repository, please refer to this article.

Selected metadata components will be retrieved from the git repository and then deployed to the Destination Org. 

Check Only option will not deploy the changes, it will be a Validation only deployment.

Test Level deploy options

  • No Test Run (not apex test are run unless is a production deployment)
  • Run Specified Tests (only included apex test classes will run, aka Fast Deploy)
  • Run Local Tests (all apex test classes excluding managed packages)
  • Run All Tests In Org (all apex test classes including managed packages)
More information regarding Test Levels

Find and Replace in files (available since Copado v3.11) allow susers to find a specific text inside the Metadata files using a Regular Expression for matching, and replacing matching pieces with a given text. Use cases for this feature are countless,  examples can be found within the Metadata step section above.

Find and Replace


Manual Tasks

This deployment step will allow reminders to be created for the deploying users.  When Copado reaches a Manual Task, the deployment process will be stopped until the Manual Task is completed.  Once set to completed, the deployment process will automatically resume.

URL Callout

This deployment step (available since Copado v3.11) will allow you to integrate Copado with other systems via HTTP calls.  The below fields are available to define the HTTP request:

  • URL
  • Method: GET | POST
  • Query parameters
  • Headers
  • Variables: Copado allows users to include the session Id, organization Id and many other variables from your Copado org as well as your Destination org.
  • Type:
    • "Perform callout and continue with the deployment":  Copado will perform the HTTP request and if a 200 OK is returned it will continue with the next step.
    • "Perform callout and pause step": Copado will perform the HTTP request.  If a 200 OK is returned, it will either wait for the resume deployment callback from the other system, or the step is marked as completed manually. The callback URL to resume the deployment will be available when selecting this option.
  • Body
Here is video where this step type is used to start regression tests on Ghostinspector before and after the deployment.

URL Callout demo


Since Copado v4.2, a Webhook lookup button is available to easily create a callout to any Copado webhook. See also URL Callouts + Webhook API

Cached Metadata

When the Metadata is loaded for the first time, it will be cached as an attachment called, ‘METADATA’ against the Org record set as the ‘From Org’ for the deployment. This file should not be edited. To refresh the cache see ‘Refreshing the cache’.

Refreshing the cache

When within a step a link at the top of the grid will be visible displaying the last cache refresh/download date. To refresh the cache press the link ‘Refresh cache (saved: LAST_REFRESH_DATE)’. Note that will be represented by an actual date and time value. Refreshing the cache may take a short while depending on the number of configurations within the Org being queried.

Whilst there are no Copado Governor Limits currently being imposed, a fair usage policy does apply.

Comments