Copado Partner Success

Training Webinars

Pipeline Automations
2020
INTRODUCTION

Nolan Larrabee
Sales Engineer
Dayton, OH
Training Considerations
● Questions can be submitted through this form, which will be
posted in the Pinned Post of our 2020 - Partner Success
Training Group in the Copado Success Community
● All questions will be stored in this sheet and can be revisited at
any time. That’s also where we’ll provide answers and
additional resources for you to consult.
● Our expectation is that you have completed all Exercises from
Session #4 prior to beginning Session #5
● Make sure all USs from previous session have been
synchronized and deployed to all environments in your
Pipeline
 AGENDA
1. Deeper Discussion on CCD
2. Review CCD Enable
3. Configure an additional
Metadata Group
4. Update your Pipeline Quality
Gates
5. Create Deployment Tasks
6. Outstanding git operations
a. Recommit Files
b. Destructive Changes
 CCD - Copado Continuous Delivery
What are the most important use cases?
● Automate deployments with user stories and promotions
● Schedule deployments with stories and promotions
● Reassure that quality gates run, before running the deployment

What are the key configuration objects?

● Connection Behavior
● Metadata Group
● Quality Gate

Where is it configured?
Pipeline Manager
Review - Enable Change Data Capture
Let’s just Review what we did in our Session 3

a. Setup > Change Data Capture

b. This list searches by API Name and it’s case sensitive.
We already selected objects in our Session 1 Pre-work:
i. copado__User_Story__c
ii. copado__Promotion__c
 Connection Behavior: What does it do?
A connection behavior allows you to define 4 things:

1. The (forward) “deployment behavior”: you can specify whether you want to schedule, automate or manually execute deployments.
a. Deployment Behavior: Manual, Automated or Scheduled.
b. Scheduled Deployment Max Batch Size: this field allows you to group user stories together.

Note: if one user story deployment fails the rest of the user stories will not be deployed either.

c. Schedule Deployments: link to configure the scheduled job.

d. Deployment Schedule: cron job expression that was configured.

Note: The Deployment Schedule field is automatically filled by Copado based on the Schedule Deployment record information.

2. The “back-promotion behavior”: you can specify whether you want to schedule, automate or manually execute back-promotions
a. Fields function exactly the same as in point #1
3. Post-Deployment Actions: What status should user stories be set to after they are successfully deployed. You can include custom picklist
values.
4. At the bottom, you can define the quality gates that will be applied: depending on the metadata contained in a US, you can decide if that
USs should pass through specific quality checks or go directly to destination.

I.e. It is not necessary to run static code analysis on a user story whose changes are not in apex code components.
Exercise Introduction - CCD Automation Exercise - CCD configuration

Next, we are going to go through several exercises to add automation to our Pipeline Connection Behaviors.

For this example, we are going to configure the Pipeline as follows:

● All Forward Deployments from ALL Dev environments to UAT will be Automated
● All Back Promotions from UAT to Dev environments will be Scheduled
● All Forward Deployments from UAT to Production will remain Manual (default)
● All Back Promotions from Production to UAT will remain Manual (default)
● All Forward Deployments from Hotfix to Production will remain Manual (default)
● All Back Promotions from Production to Hotfix will be Automated
● We also want configure our UAT and Prod Connections so that, whenever a US is deployed to UAT, the Status changes to
Ready for UAT and when it’s deployed to Production, the Status changes to Completed
Exercise - CCD Configuration - CCD configuration

First, let’s update our UAT Connection Behavior

1. Let’s make sure we are in the Copado Developer (App) → Pipeline Manager (Tab)
2. Click the “Configure Pipeline” button on the top right
3. On the UAT Environment, Left-Click on the Shield Icon to open the UAT Connection Behavior
4. In the Deployment Behaviors section, update the Deployment Behavior field from Manual (the default) to Automated; do not alter the other
fields in this section
5. Next, in the Back-Promotion Behaviors section, update the Back-Promotion Behavior field from Manual (the default) to Scheduled and
Save
6. Once the updated UAT Connection Behavior has saved, click on the Schedule Back-Promotion link and set the Schedule to Daily at 00.00 and
Save
a. This is typically recommended since it allows pipeline synchronization during the night and if there are any conflicts in the process (depending
on the components you excluded from Autoresolve) those will not go through until you intervene.
7. Finally, in the Post Deployment Actions section, select the “Ready for UAT” value for the status of the User stories when they are successfully
deployed, and click Save
Exercise - CCD Configuration (cont’d)
Next, let’s update our Production Connection Behavior

1. Navigate back to the Pipeline Manager (Tab) and click the “Configure Pipeline” button on the top right
2. On the Production Environment, Left-Click on the Shield Icon to open the Production Connection Behavior
3. In the Deployment Behaviors section, we are going to keep the Deployment Behavior field as Manual (the Default)
a. This just means that we will use the Release Manager view of our Pipeline to push User Stories from UAT to Production
4. In the Back-Promotion Behaviors section, we are also going to keep the Back-Promotion Behavior field as Manual (the Default)
a. This just means that we will use the Release Manager view of our Pipeline to Back-Promote User Stories from Production to UAT
5. We will make a change, in the Post Deployment Actions section, select the “Completed” value for the status of the User stories when they
are successfully deployed, and click Save
Exercise - CCD Configuration (cont’d)
Finally, let’s update our Connection Behavior between Hotfix and Production

1. Navigate back to the Pipeline Manager (Tab) and click the “Configure Pipeline” button on the top right
2. On the connector between the Hotfix Environment and the Production Environment, Left-Click the Elipses (...) to open the Hotfix to Production
Connection Behavior
3. In the Deployment Behaviors section, we are going to keep the Deployment Behavior field as Manual (the Default)
a. This just means that we will use the Release Manager view of our Pipeline to push User Stories from Hotfix to Production
4. In the Back-Promotion Behaviors section, update the Back-Promotion Behavior field to Automated and click Save
Check-point - Let’s confirm our CCD Configuration
Now that we have made our updates to the Pipeline, here is what our Pipeline should look like in Configuration mode.
 Connection Behavior: Considerations
● Every connection in your Pipeline can have a connection behavior.
● The connection behavior used in Promotions/Deployments/Back-Promotions can either be defined:
○ by an upper environment or
○ by a discreet connection between any two environments
● By editing the Deployment Behaviors at an Environment, you are defining the default behavior for all connections coming into that Environment.
○ This is called an Incoming Connection Behavior and it is useful in cases where there are many incoming connections to a single
environment (like UAT), since you only have to define the incoming connection behavior one time to apply to all lower environments.
○ In this scenario, not only is the configured "Deployment Behavior" applied to User Stories promoted/deployed from lower environments to the
upper environment, such as UAT, but the configured "Back Promotion Behavior" also gets applied to all User Stories pushed into the upper
environment, such as UAT, and controls how Back Promotions are sent back down to the other sibling lower Environments to keep them in sync
● There may be cases, however, when you want to have a special override behavior for one particular Connection that is different from the behavior
defined by an upper Environment
○ This is called an Outgoing Connection Behavior and it is configured on a connection between two discreet Environments, as we did on the
Hotfix to Production Connection Behavior a moment ago
○ In this scenario, the configured "Deployment Behavior" is applied to User Stories promoted/deployed from a discreet lower environment to a
discreet upper environment, such as UAT, and the configured "Back Promotion Behavior" is applied to all User Stories pushed into a discreet
upper environment, such as UAT, to control how Back Promotions are sent back down to the discreet lower environment, regardless of the
Incoming Connection Behavior defined on the upper environment

For more information, go to the section: “Connection Behaviors” on the following article:
https://docs.copado.com/article/rk426859q5-pipeline-configuration
 Pipeline Quality Gates
● Your goal is to achieve velocity as well as quality.
● Therefore Copado offers to increase the level of QA for automated deployments by configuring Quality Gates
on your Connection behaviors.
● Quality Gates are applied to Metadata Groups which represent a subset of the Metadata you potentially
deploy, as your QA process might have some special features for specific metadata.
 Exercise - Configure a new Metadata Group
CREATE METADATA GROUP FOR DATA MODEL COMPONENTS

1. Go to the AppLauncher (aka “Waffle”)

2. Search for and select Metadata Groups
3. Create a new Metadata Group
a. Name = Data Model
4. Click Save
5. Now, let’s add a Component to the Group.
6. In your new Metadata Group, on the Metadata Items Related List, click
“New”
a. Select “Custom Object” as the Metadata Type
7. Click Save
8. Click on the Parent Group “Data Model” to return to the Metadata
Group
9. On the Metadata Items Related List, click “New”
a. Select “Custom Field” as the Metadata Type
10. Click Save
11. Click on the Parent Group “Data Model” to return to the Metadata
Group
 Exercise - Update our Connection Behavior Quality Gates
As we have gone through Sessions 3 and 4 in Training, we realized that one of our Quality Gates is redundant, so we are going to make
some modifications to our UAT and Production Connection Behaviors’ Quality Gates and we are going to update our Hotfix to Production
Connection Behavior to have these updated Quality Gates too.

UPDATE OUR UAT CONNECTION BEHAVIOR’S QUALITY GATES

1. Let’s start by making sure we are in the Copado Developer (App) and the Pipeline Manager (Tab)
2. Click on the Shield icon on the UAT Environment to edit the UAT Connection Behavior
3. Since our first Quality Gate with Type “Apex Tests with Validation” already includes a Validate-only Deployment, our second Quality Gate
with Type “Validation” is redundant for the Metadata Group “Apex Classes and Triggers”, so let’s update that second Quality Gate and
apply it to our Metadata Group “Data Model” instead
4. Click the drop-down in the far-right of the Quality Gates related list for Quality Gate Validate-only Deployment and chose Edit
a. Update the Quality Gate Name: Validation Deployment for Data Model Items
b. Update Metadata Group (Lookup): Data Model
5. Save
 Exercise - Update our Connection Behavior Quality Gates (cont’d)
UPDATE OUR PRODUCTION CONNECTION BEHAVIOR’S QUALITY GATES

1. Let’s start by making sure we are in the Copado Developer (App) and the Pipeline Manager (Tab)
2. Click on the Shield icon on the Production Environment to edit the Production Connection Behavior
3. Since our first Quality Gate with Type “Apex Tests with Validation” already includes a Validate-only Deployment, our second Quality Gate
with Type “Validation” is redundant for the Metadata Group “Apex Classes and Triggers”, so let’s update that second Quality Gate and
apply it to our Metadata Group “Data Model” instead
4. Click the drop-down in the far-right of the Quality Gates related list for Quality Gate Validate-only Deployment and chose Edit
a. Update the Quality Gate Name: Validation Deployment for Data Model Items
b. Update Metadata Group (Lookup): Data Model
5. Save
 Exercise - Update our Connection Behavior Quality Gates (cont’d)
ADD OUR TWO QUALITY GATES TO OUR HOTFIX TO PRODUCTION CONNECTION BEHAVIOR

1. Let’s make sure we are in the Copado Developer (App) → Pipeline Manager (Tab)
2. Click on “Configure Pipeline”
3. Since we want to ensure that our 2 Quality Gates get triggered any time that our User Stories are deployed from Hotfix to Production, click on the
shield icon on the Connector between Hotfix and Production
4. Scroll down to the Quality Gates related list and click the New button
5. Let’s add our first quality gate with:
a. Name = Apex Tests (Selected)
b. Type = Apex Tests with Validation
c. Metadata Group = Apex Classes and Triggers
d. Apex Test Level = Run Specified Tests
6. Click Save
7. Now click on the Parent Connection Behavior “Hotfix to Production Behavior” to return to the Connection Behavior
8. Ok, so we have our Apex Tests with Validate-only Deployment for our Metadata Group “Apex Classes and Triggers”, now let’s add a second Quality
Gate for a Validate-only Deployment for our Data Model Metadata Group
9. Scroll down again to the Quality Gates related list and click the New button
10. Let’s add our second quality gate with:
a. Name = Validation Deployment for Data Model Items
b. Type = Validation
c. Metadata Group = Data Model
11. Click Save
12. Now click on the Parent Connection Behavior “Hotfix to Production Behavior” to return to the Connection Behavior
 Pipeline Quality Gates - Considerations
● Bear in mind that Copado runs deployments using the org credentials for each environment. This security feature allows teams to define different credentials
for different users in each environment.
● If you have automated deployments using Continuous Delivery, when a developer submits a user story this can trigger a series of deployments to different
destination environments. Those deployments will each run using the org credentials of that user.
● It is possible to use Continuous Delivery to allow developers to deploy their work to different environments, even if they don’t have their own org
credentials for that particular environment. To do this, simply set a default org credential for these environments. The default org credential will enable
Continuous Delivery to deploy user stories to that environment, even if the developer doesn’t have their own access.
● Only someone with the Copado Release Manager license can deploy to production orgs. If you want to enable Continuous Delivery to automatically
deploy certain kinds of user stories to production orgs, someone with a Copado Release Manager license will need to assign a default org credential to
the production org.

Note: The Copado Release Manager license is the one that in the Copado License Manager page has the “Copado User” option enabled. This license is
designed for user who are in charge of:

● Support end-to-end user story development process definition.

● Approve user stories for deployment.
● Coordinate conflict resolution.
● Make sure all quality gates have been met.
● In charge of deployments and releases to production.
● Monitor deployment activity through Copado reports and dashboards.
● Manage and sync environments and Git branches.

● Scheduled deployments or back-promotions in Continuous Delivery behave differently. These jobs are performed by a scheduled job user.
Exercise - Testing CCD
IN DEV1

1. Login to Dev1
2. Navigate to Setup > Object Manager > Planet Object >
Planet > Fields & Relationships
3. Click on New
a. Type: Number
b. Label: Mass
c. Length: 18
4. Click on Next
a. Select the checkbox “Read-only” for all the profiles.
5. Click on Next
6. Click on Save & New
a. Type: Checkbox
b. Label: Has a Ring System?
7. Click on Next
a. Assign to all profiles
8. Click on Next
a. Don’t assign to any layout
9. Click on Save
10. Go to the Astronomer Permission Set and give edit access
to the Mass field only
 Exercise - Testing CCD (cont’d)
IN COPADO

1. Navigate to the User stories tab

2. Click on New
a. Title: New Mass field
b. Project: Training Project
c. Org Credential: Dev1
d. Click on Save
e. Go to Commit Changes
i. Refresh the grid
1. Look for “Planet” and select
a. Planet__c-Planet Layout (layout)
b. Planet__c-Gas Giants (layout)
c. Mass (customField)
d. Has a Ring System? (customField)
2. Look for and select the Astronomer (Permission Set)
ii. Click on Commit Changes

Once the commit is finished, go to the User Story selection:

unwantedly we selected the Has a Ring System? field and it’s now
included in our commit. We don’t want it there because Business
requested not to deploy it. Let’s fix that.
Exercise - Remove Selections
1. In this same User Story, click on Commit Changes again.
a. In the Git Operation picklist select Recommit files
b. Check the Re-Create Feature Branch checkbox
c. Deselect the Has a Ring System? (customField)
d. Click on Commit Changes
 Remove Selections From Story? Recommit & Recreate
● If the Re-Create Feature Branch checkbox is not checked, Copado will do the following when committing:
○ Commit the selected metadata components in the existing feature branch. If the feature branch is not found (because it was deleted
manually in the Git repository), Copado creates a feature branch automatically.

● If the Re-Create Feature Branch checkbox is checked, Copado will do the following when committing:
○ Delete the existing feature branch in the Git repository.
○ Create a new feature branch.
○ Commit the selected metadata components.

Note that if you check the Re-Create Feature Branch box, the newly created feature branch will not include the previous commits in the user
story, and the status of these commits will be set to Commit not in branch.

Once the commit goes through, you can check the User Story Selections to make sure everything we need is in there and the User Story
Commits to see that the previous commit has a status “Commit not in branch” and that the new is Complete.
 Deployment Task Automation
In order to release a functionality in salesforce, often it’s not sufficient to deploy, but also to execute pre and post deployment steps, such as
creating custom setting record, migrating data or activating salesforce functionality.
Copado let’s you keep track of additional tasks for stories and also provides the technology to automate a majority of those tasks. For
instance:

● Use Manual Tasks to keep track of tasks and provide instructions for steps which cannot be automated.
● Data Type / Data Templates (ADD only) can be used to move data from one org to another, e.g. for CPQ Configuration
● Custom Setting allows you to migrate custom setting records
● Apex allows you to run Anonymous apex on the target org to create data or dynamically set a custom setting with an org-specific Id
 Why Use Manual Task as a Deployment Task?
When it comes to manual configuration, most companies rely on spreadsheets to note down all the required tasks.

This means that release managers need to ensure that all the relevant users have access to the documents and, on some occasions,
“chase” them to have the tasks completed within the deadlines set.

Common use cases:

● Configure settings that are not supported by the Metadata API: Certain metadata types are not deployable through the Metadata API and
require manual intervention.
● Make sure a release notification is sent: A huge part of your release process lies in informing your users about the new features and
when they will become available. You can create a Manual task so that the user in charge doesn’t miss any communication.
● Necessary manual steps in Installed Packages: Some installed packages need manual steps for their setup to be completed.
Exercise - Manual Task
1. Go to our most recent User Story
2. Go to the Related Tab and navigate to the Deployment Tasks related List.
3. Create a new Deployment Task and set the Type to “Manual Task”
4. Deployment Task a Name: Notify Astronomy Team
5. Status: is informational, but let’s set it to “Pending”
6. Perform Deployment Task: Before Deployment, since we’ll issue the notification before moving the changes
7. Order: 1
8. Task Details
a. Task Owner: since this is a Trial org, select your own user. Otherwise, here you’ll define the owner who’ll be notified to execute this task
during the deployment window.
b. Notify Task Owner: select the notification channel for the owner. Select Email.
i. In order for the chatter notification to work, the chatter feed must be enabled in the deployment object. This can be enabled in Setup >
Feed Tracking.
c. Perform in Source Org and Perform in Destination Org(s)Mark the Perform in Destination Org(s) checkbox.
d. The Perform in Source Org and Perform in Destination Org(s) checkboxes only add information for the Task Owner about the Org where
they are required to perform the Task. Mark the Perform in Destination Org(s) checkbox.
e. In Task Description provide an explanation of the Task:

“The Astronomy team has requested the release team to notify them when the Mass field is about to be deployed both to UAT and
Production. The release manager should send an email to the astronomy team distribution list before deploying changes. No approval is
required from the Astronomy team. This is just informational”

9. Click Save
 Why Use Apex as a Deployment Task?
The Apex task lets you execute an Apex Anonymous script in the destination org.

Apex tasks are used to automate actions that cannot be deployed via the Metadata API and are available using Apex.

Furthermore, with Copado Apex tasks you can keep a record of when an Apex script has been executed, who wrote it and its content.
Deployment tasks are stored in your org, whereas logs in the Console are deleted automatically by Salesforce.

Common use cases:

● Unscheduling of scheduled Apex jobs: After applying changes in an Apex class, leverage the Apex step to unschedule the Apex jobs prior
to the deployment. Use a second Apex step to reschedule the newly modified Apex class.
● Permission Set Assignment: Assign permission sets to specific users upon permission set deployment.
● Data cleansing or small updates: You can run an Apex task to delete records in order to comply with security policies or just free up data
storage in your production org.
Exercise - Apex Task
1. Go back to the previous user story.
2. Navigate to the Deployment Tasks related list
3. Click on New and set the Type to “Apex”
a. Name: Astronomy PS Assignment
b. Status: is informational, but let’s set it to “Pending”
c. Perform Deployment Task: After Deployment
d. Order: 1
e. Apex Script:
i. We posted the raw text file in the Files section of our Partner Training (May 2020) Group in Success
1. The file is labeled "Apex Script for Session 5"
ii. Copy the contents out of that file and paste in the Apex Script field of your Apex Deployment Task
f. Click Save
 Deployment Task Considerations
● Although Deployment Steps will be positioned according to the order given to Deployment
Tasks, you can still reorder them in the Deployment record, before launching the
deployment. If you have assigned the same order value to more than one Deployment
Task within the same US, they will be ordered based on the Created Date field.

● If you are promoting multiple user stories with Deployment Tasks associated, the
Deployment Tasks will be first ordered by
○ The User Story merge order (User Story number unless you’re using a custom field for
the sorting)
○ Then the Order field and if the Order value is the same
○ Then the Created Date field
 Quick Refresher on the Submit button on User Stories
This button submits our User Story into the CCD stream we have configured and uses the
underlying Pipeline configuration and Connection Behaviors that we have defined
throughout our Pipeline.

After clicking the Submit button, you are redirected to a confirmation page showing a
summary of the upstream environments, dependencies (if any have been manually set
between the User Stories), deployment type to the next environment (automatic, manual or
scheduled) and what Quality Gate(s) will run beforehand.
Exercise - Submit Your User Story
1. Go back to our most recent User Story and click the Submit button
2. You should've received an email informing you that “There is a manual task waiting for your intervention”
3. You can navigate to the Deployment record directly from the email
4. Once in the Deployment, go to the Steps section. You’ll see:
5. The Manual Task and a Status to indicate if it’s Complete or Incomplete
a. Complete means that it’s been done in the corresponding Org (in our case destination) and upon clicking Update, Copado
will ask you for a comment (you can leave it empty) and will resume the deployment and kick the next step.
b. Incomplete means that for any reason, that action cannot be executed and you’ll be prompted to specify why
c. If you open the step you’ll see the description and more information about the manual task.
d. Let’s assume you’ve sent the notification. Select Complete and click on Update.
6. Validation: this is the Validation Deployment Quality Gate that’s been configured for the Data Model Metadata Group. If
successful, it’ll continue with the actual deployment. Otherwise, the deployment will stop.
7. Git Promotion: this is the actual deployment that will be executed if the Validation Deployment is successful
8. Apex Task: it will be executed if the previous step (git promotion) is completed successfully

Note: If any of the deployment steps fails, you can fix the issue and continue the deployment without restarting the complete deployment with all the steps.

When you click on Deploy, you will be prompted to Deploy All which means restart the deployment or Deploy Outstanding which means continue the
deployment from the failed step.

Once all the steps are successfully completed, the deployment status will change to “Completed Successfully”.
Before we continue...

LET’S MAKE SURE ALL OF TODAY’S USes ARE DEPLOYED TO PRODUCTION AND RECONCILE THE PIPELINE

I. Use Submit on Today’s User Story to move it all the way up to Production
A. If any Submit indicates that Promotion/Deployment is Manual, make sure to use the Pipeline Manager to
complete
B. If any Submit indicates that Promotion/Deployment is Automated, just monitor the User Story’s auto-created
Promotion Record and Deployment to ensure it is successful

EVEN IF YOU SEE {#} ← NEXT TO DEV1, DEV2 OR HOTFIX, REMEMBER THAT WE HAVE AUTOMATED OUR
BACK PROMOTIONS FOR THESE ENVIRONMENTS, SO DO NOT MANUALLY BACK PROMOTE ANY
MORE...COPADO WILL TAKE CARE OF THAT!
 Destructive Changes Overview
Not all of our creations are perfect, and some need to be deleted from higher orgs.

When working with Git, it’s not only about deleting the Metadata in other orgs, but also to make sure references in Git are removed.

Some Saleforce metadata, especially fields, create many references (Layouts, Profiles, Perm Sets), so that removing it from the repo can
be tricky.

Therefore Copado has a specific Destructive Changes Git Operation type that will remove the desired changes from both Git and
Salesforce.

Destructive Changes is a Git operation that can be executed from the Git Snapshot or the User Story Commit Pages.
Exercise - Destructive Changes
IN COPADO

1. Make sure we are in the Copado Developer (App) → User Stories (Tab)
2. Click on New
a. Title: Delete Distance to Earth field
b. Project: Training Project
c. Org Credential: Dev1
d. Save
e. Go to Commit Changes
i. In the Git Operations select “Destructive Changes”
ii. In the grid select
1. Distance to Earth (customField)
iii. Click on Commit Changes

Once the destructive changes commit is finished, in the User Story Selections you will find the deleted components (flagged as
Git Deletions) and any other component that was updated in case it was referencing the deleted component (flagged as
Git Upserts). In our case we see the Planet Object as Git Upsert.

You can now use the Submit button to move the User Story upstream. A validation deployment will be created per our
Pipeline configuration since we have committed a custom field .
 Destructive Changes - Considerations
Deletion Deployments in Salesforce is a tricky operation in general. Some deletions will require to also update your metadata to fix
references (e.g. if a field is part of a Class or Validation Rule).

Copado will not delete in the source org the components when using the Destructive Changes actions. It will delete them in the org and
feature branch though.

So, if you want to delete items, it’s recommended that you don’t delete them in source, so it’s easier for you to select them in the grid,
commit them, and once the commit is done, then delete them in source and deploy the US forward so in the following environments
they get deleted both in git and the org.

Note: If the component does not exist in master (where the Feature branch is checked out from) you can use the Advanced button
in the Commit Changes page to select a different branch where the component does exist (like UAT).

The Commit Advanced Module in the Copado Academy and our Documentation has more details for Destructive changes.
HOMEWORK BEFORE SESSION #6

LET’S MAKE SURE ALL OF TODAY’S USes ARE DEPLOYED TO PRODUCTION AND RECONCILE THE PIPELINE

I. Use Submit on Today’s remaining User Story to move it all the way up to Production
A. If any Submit indicates that Promotion/Deployment is Manual, make sure to use the Pipeline Manager to
complete
B. If any Submit indicates that Promotion/Deployment is Automated, just monitor the User Story’s auto-created
Promotion Record and Deployment to ensure it is successful
II. Last, but not least, make sure to delete the Distance to Earth field in Dev1

EVEN IF YOU SEE {#} ← NEXT TO DEV1, DEV2 OR HOTFIX, REMEMBER THAT WE HAVE AUTOMATED OUR
BACK PROMOTIONS FOR THESE ENVIRONMENTS, SO DO NOT MANUALLY BACK PROMOTE ANY
MORE...COPADO WILL TAKE CARE OF THAT!
THANK YOU!
Thank you so much for being a part of the Copado Ohana, for your Partnership and for your commitment to Copado Partner Training!

Nolan Larrabee
Sales Engineer
Dayton, OH