Copado Partner Success

Training Webinars

Copado Overview and Setup

2020
Welcome, Introductions and Housekeeping

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 Prerequisites prior
to beginning Training
 AGENDA

1. Copado Overview
2. Initial Copado
Configuration
3. Org Credentials
4. Environments
5. Git Repository
6. Git Snapshots
7. Pipeline
8. Projects
9. User Stories
10. Homework
DevOps Enables You to Operate Salesforce Faster with More Trust
Only 10% of CIOs say they are very successful at rapid software development and deployment

INNOVATION VELOCITY
CREATE TEST DEPLOY RELEASE

SFDC DevOps Needs

DELIVERY PIPELINE
Structured release process Go
Version control repositories

Automated deployments and testing

Keeping orgs and sandboxes in sync

Preventing merge conflicts

Collaborative development tools

SALESFORCE Integration with 3rd party DevOps tools
PLATFORM FEEDBACK LOOP
Ensuring compliance Live!

Go-Live Gap
PLAN MONITOR

TRUST & QUALITY

"What drives software flexibility? The close-in answer is the platform, but the less
obvious companion is DevOps."
 Our Goal: Help Customer Get the Most Out Salesforce
By Unifying the Delivery Team With a Complete Native DevOps Platform

CIO

Copado DevOps Platform

Native Experience
DEVELOPER ARCHITECT

Prebuilt Integrations
INNOVATION DELIVERY PERFORMANCE

➔ Leverage the Underlying Platform that you Know Complete CI/CD Processes

➔ Faster Time to Market

100% Salesforce
➔ More Secure, Predictable and Stable Releases

➔ Derisk Complex Implementations

➔ Align Business Goals With Technology

SECURITY ADMIN
➔ Optimize your Team’s Performance
Our Architecture
Built natively on Salesforce to support enterprise performance, trust and scale

Customer’s domain Copado’s domain

Dev 1

Integration UAT Prod

Dev 2
Backend infrastructure to
support heavy lifting operations
and scale at trust

Customer VCS Platform APIs

(Cloud or On-Premise) Oauth Authentication
Copado Package
Initial Copado Configuration

1. Assign the Copado Deployer AppExchange License

2. Assign the “Copado User” Permission Set
3. Create and Authenticate your own Org Credential against the Org where Copado is
Installed
4. Assign your User the different Copado Features Licenses
5. Generate your Personal API Key for Copado
Step 1: Assign the Copado Deployer AppExchange License

1. Login to your Salesforce org where Copado is installed

2. Go to Setup
3. Navigate to Installed Packages
4. Click on the “Manage Licenses” link next to the “Copado Deployer” package.
5. Click on the “Add Users” button.
6. Add all the users that need to have access to Copado.

Note: The user that was used to install the package is already added to the list.
Step 2: Assign the “Copado User” Permission Set

1. Navigate back to Setup

2. Go to Permission Sets
3. Click on the “Copado User” permission set.
4. Click on the “Manage Assignments” button
5. Assign the permission set to all the users that are going to access Copado data model and
features.

Note: In case it is required to have different levels of permissions for the Copado features and
objects, a new permission set would need to be cloned from this one and the permissions should be
modified accordingly for different levels of user permissions.

The “Copado User” permission set gives all the permissions to all the features and objects in Copado.
Nevertheless, the user also requires the proper Copado feature license(s) assigned to perform every
action in Copado.
Step 3: Create and Authenticate your own Org Credential for
Production
CREATE

Note: We must always Create and Authenticate our own Org Credential against the Org where Copado is
Installed first. In Copado, the Org Credential is a connection between your User in the Org where Copado is
installed and Copado, so this first step authorizes you as a Copado User.

To begin, let’s select the Copado Release Manager (App) → Getting Started (Tab) → Org Credentials
(Subtab)

1. Fill the following fields:

a. Org Name: Production
b. Org type: Production/Developer.
2. Click Create
Step 3: Create and Authenticate your own Org Credential for
Production (cont’d)
AUTHENTICATE

Now, you should see your new Org Credential under “Existing Org Credentials”

1. Click the “Authenticate” button

2. You will be redirected to a Salesforce Login Page
3. Enter your Username and Password for the Org where Copado is Installed
4. Click Login
5. When prompted, click “Allow” to indicate that you are allowing Copado to authenticate your User in the Org where
Copado is installed
6. When the screen updates, you will be back in Copado on your new Org Credential, do not change anything, just
click the Save button
7. You should see a green “Success: Credentials validated” message
8. Because the Authentication runs in a new Session, when you close this tab and return to Getting Started, you must
refresh the page in your Browser
9. Return to the Org Credentials (Subtab) and see that your Existing Org Credential is now Authenticated (“Open Org”
button has replace “Authenticate” button)
Step 4: Assign Copado Feature Licenses to your User
There are different licenses that need to be assigned to the users according to the actions they are going to
perform. For more information, go to: https://docs.copado.com/article/qxi5x9mk6f-copado-license-manager

For this exercise, we will assign the Copado user license to your user.
1. We are currently in the Org Credentials (Subtab) of Getting Started
2. Now, click the Account Summary (Subtab) - one tab to the right
3. Click the “Assign Licenses” button
4. At the top of this new page, you will see a summary of all the licenses available for your organization.
a. For each Copado Feature License type, you will see two numbers separated with a “/”
b. The first value is the number of licenses of that type currently assigned to Copado Users and the
second value is the total number of that type which has been provisioned in your Org
5. In the User Lookup field, search for and select your user
6. Check the “Assign Copado License” checkbox
7. Check the “Assign CCM License” checkbox
8. Check the “Assign ADD License” checkbox
9. Click the Add/Update User button
Step 5: Generate your Personal API Key
A Copado API key allows actions to be scheduled securely and validated in the Copado server. For
example, an API key is required for webhooks (such as Pull Requests), scheduled jobs (such as
Nightly Refresh of Metadata) and CI/CD Automation.

Let’s create our Personal API Key

1. We are currently in the Account Summary (Subtab) of Getting Started
2. In the bottom section “Account Summary”, click the “Create/Reset” button
3. Click on the center tab labeled “API Key”
4. Click “Create/Reset”
5. Once your API Key appears, close this tab - it is not necessary to copy your API Key
6. We should be back in the Account Summary (Subtab) of Getting Started
7. In the bottom section “Account Summary”, click the “Refresh” link and you will see your API Key
Org Credentials: Overview
An Org Credential is a key element to how Copado Works. It represents a User’s access to a Salesforce environment.
It is key that the first Org Credential to be validated is the one that connects the User to the Organization where Copado is installed.

● Copado will use each Org Credential to authenticate to the corresponding Org during the commit and deployment operations.
● This means that the activities Copado can perform on both Source and Target orgs are governed by the permissions the
authenticating user has been given by your Organization’s Administrators
● Since Org Credentials represent user accesses, Org Credentials are a private object in the Salesforce sharing model and we do not
recommend changing that.
● Every org that needs to be accessed through Copado needs to have at least one Org Credential.
● Org credentials can be created per named user, or you can have shared Org Credential which can be marked as “Default”. We
recommend establishing a naming convention for Org Credentials. For example “initials_Org Name”. E.g.: JD_UAT.
● Unless you’ve got restrictive compliance or security requirements, we recommend creating a set of Default org credentials that are
later shared with the team. This makes maintenance and onboarding easier, while keeping tight control who can access what org.
● Org credentials are also used to index the metadata that a user has access to and to define what metadata component types that
Org Credential can “access”.
Exercise: Create your Remaining Org Credentials
For this session, we have already created our Org Credential for the Org where Copado is Installed (aka “Production”), so now we need to Create and
Authenticate our own Org Credential for each of the Sandboxes we will be using during Training: UAT, Dev1, Dev2 and Hotfix.

1. Let’s first make sure we are all back on the Copado Release Manager (App) → Getting Started (Tab) → Org Credentials (Subtab)
2. Fill the following fields:
a. Org Name: UAT
b. Org type: Sandbox
3. Click “Create”
a. Now, you should see your new Org Credential under “Existing Org Credentials”
4. Click the “Authenticate” button
5. You will be redirected to a Salesforce Login Page
6. Enter your Username and Password for the UAT Sandbox that you created as a Prerequisite
7. Click Login
8. When prompted, click “Allow” to indicate that you are allowing Copado to authenticate your User in your UAT Sandbox
9. When the screen updates, you will be back in Copado on your new Org Credential, do not change anything, just click the Save button
10. You should see a green “Success: Credentials validated” message
11. Close this tab and return to Getting Started
12. On the Org Credentials (Subtab) click the “Refresh” link to see that your UAT Org Credential is now Authenticated (“Open Org” button has replace
“Authenticate” button)

Repeat these steps to create your remaining Sandbox Org Credentials for: Hotfix, Dev1 and Dev2. Remember, for each that the org type will be Sandbox.

For more information, go to How to Create an Org Credential

Environments: Overview
An Environment represents a specific Salesforce organization. Environment records are created
automatically when the first Org Credential related to that Salesforce Org is authenticated.

● The Organization ID will be the external ID.

● An environment can have multiple Org Credentials (user-specific connections) related to it.
● By default, the environment name will take the Org Credential name when it is created, but
you can update it afterwards.
● Among other things, you can define different Apex Test behaviors in the Environment record,
like enforcing Copado to run all local tests, or modify the Minimum Apex Test Coverage
required (> 75%), to emulate a behavior similar to Production.
Exercise: Review the Environments that Auto-created
Let’s take a look at the Environments that created from our Org Credentials

1. We should still be in the Copado Release Manager (App)

2. Click on the “Environments” tab
3. In the “All” List view, you should see an Environment record for each Org Credential
that you created: Production, UAT, Hotfix, Dev1, Dev2
a. Notice in the “All” List view, that each Environment has a 75% Minimum Apex
Code Coverage
b. Copado allows us to set a Minimum Apex Code Coverage requirement for every
Salesforce Environment that we will work with in Copado; this is very helpful to
ensure that we do not get surprised when Deploying to Production and suddenly
find that our Code Coverage is below the minimum threshold that Salesforce will
require in Production
Git Repository: Overview
The Git Repository record in Copado represents the relationship between Copado and the VCS (Version Control System) which you are
using. The Git Repository record is a critical element of the setup and is required in order to enable Copado to synchronize and run the git
operations.

● The Git Repository Record will store the Authentication between Copado and the VCS Repository (SSH and HTTPs are supported).
● In addition to your working repository it is best practice to set up a backup repo which will not be used in your deployment
Pipeline, but will contain a backup of all the metadata from all of your Salesforce orgs, and a training repository which can be used
to train/onboard new users and test any functionality following Copado releases. We will dive deeper into Implementation Strategies
in future Training Sessions.
● To initiate your repository you can create a .gitignore and a Readme file (if required). A sample gitignore file can be found here.
● We recommend that you also compile a list of managed packages which exist in your org and add the elements of the managed
packages which you cannot customize to your .gitignore, if you have several managed packages in your org this will save significant
repository space and result in better performance over time, also since you cannot modify these components it does not make sense
to version these in Git.
● There is a One-to-One relationship between the repository and a Pipeline within Copado - this should be considered when planning a
new Pipeline
● Copado supports all the git based providers (GitHub, GitLab, Bitbucket, Azure Repos, etc.)

IMPORTANT: You and your Users do not need to be familiar with Git; Copado will handle all Git Operations through simple points and
clicks from the familiar Salesforce UX, but during this Training, we are going to share with you some of the “Under the Hood” happenings,
just to enhance your knowledge of Copado’s Git Integration for Version Control.
Exercise: Create a Git Repository record in Copado
We should still be in the Copado Release Manager (App) and we should click the Getting Started (Tab) and the Git
(Subtab); make sure you have also logged into your Git Account where your Training Repository has been created.

1. Click the “New Git Repository” button

a. Git Repository Name: Copado Training Repo
b. Source Format: Metadata
i. Note: For this training, we will keep the default Salesforce Metadata selection. This Training will not cover
Dx
c. Authentication type: SSH
d. URI: Include the URI of your repository
i. Explain how to get it
e. Git provider: Github
i. Notice that Copado templatizes the remaining fields and you only need to replace
{Username}/{RepositoryName} with the corresponding values from your Github Repository
ii. Copado Tip: copy your Username and Repository name from the URL of your Repository
f. Click Save.
i. At this point, you should get a red warning at the top of your Github Repository record; this is expected
Exercise: Create a Git Repository record in Copado (cont’d)
g. Since we are using SSH as our Authentication Method, we need to click on the “Create SSH Keys” button at
the top of our Copado Training Repo record
h. Now, scroll down and look for a new section in the Record detail page labeled “Current SSH Keys”.
i. Click the View link, which will expand a new section labeled “Key Content”
j. Copy the entire key beginning with “ssh-” but make sure that you stop with the final character in the key
i. A common mistake is to copy a trailing space that generates after the Key
2. Ok, let’s pause here for a moment, if you remember, with our Org Credentials, we used native OAuth Authentication
in order to Authenticate our User to each Salesforce Org that we will be working with in Copado. Git Providers do
not use OAuth for Authentication, they either use HTTPS (“Hypertext Transfer Protocol Secure”) or SSH (“Secure
Shell) and, in this Training Series, we will be using SSH
3. Let’s go to GitHub and add the SSH Key that we just created in Copado
4. Login to or open the GitHub account that has your Training Git Repository
5. Do not go to your Training Git Repository right now; the SSH Key from Copado needs to be added to your Git
Account, rather than to a single Repository
6. Navigate to your profile (Click on the Avatar in the top-right corner)
7. Click on “Settings”
8. Then click on “SSH and GPG Keys”
Exercise: Create a Git Repository record in Copado (cont’d)
9. Click the “New SSH key” button
a. For Title use “CopaPartnerTraining”
b. For Key paste the SSH Key that you copied from Copado - make sure you did not accidentally copy the trailing
space with your Key
c. Click “Add SSH Key”
10. GitHub will likely prompt you to re-enter your Password
11. Confirm that you now see CopaPartnerTraining in GitHub
12. Let’s go back to Copado and our tab where we were working on our Copado Training Repo
13. Refresh the page in your Browser and you should now see the “Success:Credentials validated” message at the top
of the page.
Exercise: Add the Training .gitignore to your GitHub Repository
Now that our Training Git Repository is connected to Copado and has been authenticated, we need to initialize our Training Git
Repository’s master Branch with a .gitignore file.

1. Let’s go back to Github and navigate to your Training Repository

2. Click the “create a new file” button
3. Name your file .gitignore
4. Copado has created a sample .gitignore file for this training, which is also posted in our Partner Training Group on Success. This
sample .gitignore file excludes:
○ Package XML
○ Installed Packages
○ Copado managed package code components
○ Documents
5. Highlight and copy lines 1 - 38 of the Copado sample .gitignore
6. Now, return to your open browser tab with your own GitHub Training Repository where you have started your new .gitignore file
7. Down in the body, paste the contents
8. Let’s take a moment to read through some of the Comments throughout this Copado sample .gitignore - all comments start with #
and provide additional information to each component type we are omitting from our Training Git Repository
9. Now, scroll down, leave the default Commit message of “Create .gitignore” and keep the default selection to Commit directly to the
master Branch
10. Click the Commit New File button
Git Snapshots: Overview
A Git snapshot represents the relationship between a Salesforce Org (through an Org Credential) and a Git Branch. This
enables Copado to dynamically identify which branch in VCS/Git is related to which Salesforce Org when running the commit
and merge operations.

● Git Snapshots are child records of:

○ the Git Repository, since they represent the Environment branches of a Git Repository
○ an Org Credential, since an Org Credential identifies which Salesforce Environment is related to a Git Environment
branch
● A Git Snapshot allows Copado to take a point-in-time backup of a Salesforce Environment’s metadata and commit that
backup into the corresponding Git Environment Branch.
● A Git Snapshot is also used to initialize the master branch in the Git Repository with all of the metadata folders and files
present in your Salesforce Production Environment, excluding any metadata that we have omitted with our .gitignore file
● There are 3 types of Permissions within a Git Snapshot:
○ Allow Snapshots & Commits
○ Allow Snapshots Only
○ Allow Commits Only
● Throughout this Training, we will be working with the Permission Allow Snapshots & Commits and the Permission
Allow Commits Only
Exercise: Create a Git Snapshot for Production
We need to create one Git snapshot for each environment of your pipeline, but they will have different Permissions, depending on the type of Environment we are
working with.

First, let’s create our Production Snapshot, which will have Full Permissions.

1. Let’s make sure we are still in the Copado Release Manager (App)
2. Now, just to make sure everything has refreshed, let’s click the Getting Started (Tab) and the Git (Subtab)
3. You should now see, when you click the drop-down at “Select a Git Repository”, your recently-created “Copado Training Repo” record in the drop-down; click it to
select
4. Right below, in the section labeled “Git Snapshots” click the “New Git Snapshot” button
5. Populate the following fields ONLY
a. Git Snapshot Name: Production
b. Branch: master
i. Branch value is case sensitive, make sure to use lowercase
c. Git Snapshot Permissions: Allow snapshots & commits (aka “Full Permissions”)
i. We select the Allow snapshots & commits permission on Production because we will be taking backup snapshots from this org and we will also
be committing and pushing changes to Production as we move our metadata changes across our Salesforce Environments
d. Frequency: DO NOT do anything with this field right now
i. In a real implementation of Copado, you can configure the Production Git Snapshot record to take automatic snapshots on a Daily, Weekly or
Monthly basis; however, we will only be in Training for 2 weeks, so it is unnecessary to set this automatic job now
e. Org Credential: Production
6. Click Create
7. Once created, click on the Git Snapshot Name “Production” to open the Git Snapshot record in a new tab
8. Click on the Take Snapshot Now button
9. Keep the default Commit Comment and simply click the Ok button
Exercise: Create the 4 Git Snapshot records for your Sandboxes
All of our other Salesforce Environments in this Training are Sandboxes. Typically, we are not going to perform regular Snapshots of our Sandboxes.

Instead, we are going to Commit metadata changes from our Salesforce Sandbox Environments into their corresponding Environment Branches in our Git Repository, and Copado will handle
all of the Merging when we Promote/Deploy and Back Promote to ensure that our Sandboxes stay in synch.

1. Here on the Git (Subtab) of Getting Started (Tab), down in the “Git Snapshots” section, click the “New Git Snapshot” button
2. Let’s create our UAT Snapshot record first
○ Populate the following fields ONLY
■ Git Snapshot Name: UAT
■ Branch: uat
● Make sure to use lowercase
■ Git Snapshot Permissions: Allow Commits Only
● We select the Allow Commits Only permission on UAT because we will be committing and pushing changes to UAT as we move our metadata changes across
our Salesforce Environments
■ Frequency: DO NOT do anything with this field right now
■ Org Credential: UAT
○ Click Create
3. Because we have set the Permissions for UAT to Allow Commits Only we cannot take a Snapshot against UAT; not to worry, once we get our other 3 Sandbox Snapshot records
created, we will be heading into Git and I will show you why we are doing this
4. Let’s create our Dev1 Snapshot record next
○ Click the “New Git Snapshot” button
○ Populate the following fields ONLY
■ Git Snapshot Name: Dev1
■ Branch: dev1
● Make sure to use lowercase
■ Git Snapshot Permissions: Allow Commits Only
■ Frequency: DO NOT do anything with this field right now
■ Org Credential: Dev1
○ Click Create
Exercise: Create the 4 Git Snapshot records for your Sandboxes (cont’d)
5. Now, let’s create our Dev2 Snapshot record
○ Click the “New Git Snapshot” button
○ Populate the following fields ONLY
■ Git Snapshot Name: Dev2
■ Branch: dev2
● Make sure to use lowercase
■ Git Snapshot Permissions: Allow Commits Only
■ Frequency: DO NOT do anything with this field right now
■ Org Credential: Dev2
○ Click Create
6. Finally, let’s create our Hotfix Snapshot record
○ Click the “New Git Snapshot” button
○ Populate the following fields ONLY
■ Git Snapshot Name: Hotfix
■ Branch: hotfix
● Make sure to use lowercase
■ Git Snapshot Permissions: Allow Commits Only
■ Frequency: DO NOT do anything with this field right now
■ Org Credential: Hotfix
○ Click Create
Knowledge Only: Go into Git and View your Updated master Branch
Now, we want to go into our Training Git Repository and see our updated master Branch populated with the backup of our metadata
from our Salesforce Production Environment.

To do this easily, right from our Git Snapshot Production record, you can actually click on the master “View in Git” link in the “Other
Information” section, so long as you have not logged out of your Git Account...if you logged out, just log back in!

Look at that! Our master Branch in our Git Repository has been updated with a full backup of all of the metadata from our Production
Salesforce Environment, excluding the Metadata that we intentionally omitted with our .gitignore file.

And our metadata backup is neatly organized into the native Salesforce Metadata folders and files structure.

Let’s take a quick peek, just to see what we got. Scroll down to the folder labeled Objects and click on it, then click on
Account.object - this file is a backup of the metadata from the native Account Object.

Oh, did I not mention? That’s right, Copado works with all metadata supported by the native Salesforce Metadata API, which includes
all standard metadata!

Ok, one more quick fun thing here, do a <Ctrl-F> “Find” on this page and look for listviews - these are all of the out-of-the-box,
standard Account List Views, along with all of their Columns and Filters.
Exercise: Create Environment Branches in Git for your Sandboxes
So, now that we have had a peek at our backup here in Git, let’s navigate back to the master Branch of our Training Git
Repository - just click on the Repository Name up at the top of this page.

We should see Branch: master and all of our backup folders.

Remember when we created our Sandbox Snapshots, and we only selected the Permissions for Allow Commits Only?

That is because we are going to start all of our Environment Branches here in Git, by cloning them from our master Branch,
so they are all equal.

This is no different than how our Salesforce Sandboxes were created from Production, and therefore, all have the same
metadata as our Production Environment.

Cloning a Branch in Git is very easy, click that drop-down arrow to the right of master, then start typing, we will start with uat
but be very careful to use lowercase. Now click Create branch: uat from ‘master’

Notice the screen has updated - we now have 2 Branches, and we are currently in our uat Branch, which has everything that
we saw in master because we cloned uat from master, the same way that our UAT Sandbox is a metadata clone of our
Production Environment.
Exercise: Create Environment Branches in Git for your Sandboxes (cont’d)
Since our Dev1 Sandbox was also created from our Production Environment, let’s use the Branch drop-down and switch back to
master.

Click that drop-down arrow to the right of master, then start typing, this time we will type dev1 but be very careful to use lowercase.
Now click Create branch: dev1 from ‘master’

The screen has updated again and we now have 3 Branches, and we are currently looking at our dev1 Branch, which has everything
that we saw in master because we cloned dev1 from master, the same way that our Dev1 Sandbox is a metadata clone of our
Production Environment.

Let’s switch back to master and create branch: dev2 from master; now we have 4 Branches.

Finally, let’s switch back to master and create branch: hotfix from master; now we have all 5 of our Environment Branches in Git to
match all 5 of our Salesforce Environments.

For now, we can close the Browser Tab with Git and return to Copado.

In Copado, let’s also close that Git Snapshot Production record tab, as it has served its purpose for now.

We should be back in Copado Release Manager (App) → Getting Started (Tab) → Git (Subtab).
Pipeline: Overview
A Pipeline (AKA “Deployment Flow”) is a list of Environments defining a structured path in which our Salesforce metadata changes are
going to move through, typically from our lowest Dev Environments, all the way up to Production.

The Pipeline in Copado works as a traffic-control system for ongoing changes and releases - it allows you to visualize the path to
Production and environment connections, provides information on changes ready to deploy, the last deployment status per
environment and allows you to configure advanced CI/CD behaviors that we’ll see in other sessions. It also ensures consistency
across environments and branches as changes move through it.

● Every Pipeline in Copado should have a 1:1 relationship to a Git Repository.

● Each Environment in a Pipeline can have multiple sources it cannot have multiple destinations; for example, Dev1 and Dev2 can
both feed upstream into UAT, which then feeds upstream to Production, but Dev1 could not feed into both UAT and Production
concurrently in the Pipeline
● Copado supports multi-pipeline scenarios, meaning that different customers, business units, productions streams, etc. can be
managed by a single installation of Copado; as a reminder, we install Copado once, in a Production-quality Org
● In the Pipeline record you can configure and define different behaviours and enable/disable features, like DX workflows, Static
Code Analysis settings and others.
● The Pipeline Manager tab allows you to toggle between the traffic-control view, aka “the Release Management View” and a
“Configuration View”, which we will use later in this Training series to add CI/CD Automation to our Pipeline.
Exercise: Create our Copado Training Pipeline
In order to configure our Pipeline, let’s make sure we are in the Copado Release Manager (App), then let’s
click on the Getting Started (Tab) and let’s click on the Pipeline (Subtab).

Click the “New Pipeline” button and Populate the following fields:

● Pipeline Name: Copado Training

● Git Repository: Copado Training Repo (Select the Git repository record you created in the previous
steps)
● Main branch: master (lower case)
● Active: true

Click the Create button to complete this step.

Remain on the Pipeline (Subtab) of Getting Started.

Exercise: Add our Environments to the Pipeline
For this Training Series, we are going to create a simple pipeline - 2 Dev Sandboxes feeding into our UAT Sandbox with both our UAT Sandbox and our
Hotfix Sandbox feeding into Production.

First, let’s create our Pipeline Connection for Dev1 feeding into UAT:
1. Click the “New Pipeline Connection” button down here on the right
2. Populate the following fields:
a. Source environment - this is a Lookup: Dev1
b. Destination Environment - this is a Lookup: UAT
c. Branch - make sure to use lowercase: dev1
i. Whenever a Pipeline Connection is created, the Branch on the Pipeline Connection should always match the Source Environment’s
Branch in Git
3. Click the “Create” button

Next, let’s create our Pipeline Connection for Dev2 feeding into UAT:
1. Click the “New Pipeline Connection” button down here on the right
2. Populate the following fields:
a. Source environment - this is a Lookup: Dev2
b. Destination Environment - this is a Lookup: UAT
c. Branch - make sure to use lowercase: dev2
i. Whenever a Pipeline Connection is created, the Branch on the Pipeline Connection should always match the Source Environment’s
Branch in Git
3. Click the “Create” button
Exercise: Add our Environments to the Pipeline (cont’d)
Now, let’s create our Pipeline Connection for UAT feeding into Production:
1. Click the “New Pipeline Connection” button down here on the right
2. Populate the following fields:
a. Source environment - this is a Lookup: UAT
b. Destination Environment - this is a Lookup: Production
c. Branch - make sure to use lowercase: uat
i. Whenever a Pipeline Connection is created, the Branch on the Pipeline Connection should always match the Source
Environment’s Branch in Git
3. Click the “Create” button

Finally, let’s create our Pipeline Connection for Hotfix feeding into Production:
1. Click the “New Pipeline Connection” button down here on the right
2. Populate the following fields:
a. Source environment - this is a Lookup: Hotfix
b. Destination Environment - this is a Lookup: Production
c. Branch - make sure to use lowercase: hotfix
i. Whenever a Pipeline Connection is created, the Branch on the Pipeline Connection should always match the Source
Environment’s Branch in Git
3. Click the “Create” button
Project: Overview
Projects are the parent-level object used to group together our User Stories (work items for devs and
admins) and typically represent a high-level and long-lasting endeavour you’re undertaking, often related
with a specific product (e.g. Sales Implementation, CPQ Implementation, etc.).

The Project is technically significant for DevOps Processes because all of its related User Stories will
follow the same Pipeline, and therefore have a defined deployment path.

● Projects can be used in different Copado pages to filter User Stories that you want to deploy
● For DevOps processes in Copado, ever User Story:
○ Must be linked to a Project
○ Must have a Title
○ Must be assigned to an Authenticated Org Credential for one of the lowest Environments in the
Project’s Pipeline
● The Project is also the central integration object for Copado ALM integrations
● Copado also has a native ALM suite in the event that you do not already have an external ALM
platform such as JIRA or Azure DevOps
Exercise: Create our Training Project
We should still be in the Copado Developer (App), so let’s click on the “Projects” tab.

Click the “New” button and populate the following fields:

1. Project Name: Training Project

2. Pipeline - this is a Lookup: Copado Training
3. Index metadata: true

Click the “Save” button.

For more information, https://docs.copado.com/article/x03j4oj678-project-overview-and-setup

User Story: Overview
Most of the daily activities that Admins and Developers will do in Copado revolve around User Stories - they are a central piece of how Copado
works.

Copado’s User Stories allow the alignment of Functional and Technical Requirements, the Commit of Metadata Changes to the VCS, execution and
summary of Quality checks and the deployment of the related changes.

This gives you the ability to easily track and report on specific changes and helps ensure that you know exactly what’s being promoted in the
Pipeline.

● The User Story is uniquely identified in Copado by an auto-number field US-XXXXXXX.

● The US identifies its deployment path through the Project/Pipeline relationship. You have a visual path in the US layout.
● US are tied to Feature branches, which enable you to deploy them individually, quickly and independently.
● There are many out-of-the-box fields on the User Story, most which may not be relevant to your process. Since Copado is on top of Salesforce,
you can modify, remove and/or create new layouts to make the view more aligned to your needs. The recommended fields to maintain and
complete are:
○ Title: Not technically required though it allows you to identify the User Story purpose
○ Project: technically required to deploy the US. It defines, through the related Pipeline, the deployment flow.
○ Org Credential: identifies the retrieve access and the environment where the US originated and will be worked.
○ Environment: will be automatically populated based on the Org Credential.
● As the US gets deployed through the Pipeline, the Org Credential and Environment fields will be automatically updated by Copado.
● There are multiple Quality Gates that can be triggered from an US to enable admins and developers to prioritize quality at the early stages of
the development life cycle (Apex Tests, validation deployments, SCA, Pull requests, etc.).
Exercise: Create a New User Story
In your Training Project record, go to the related lists, find the User Stories (Related List) and click the
“New” button using the “User Story” Record Type.

Copado Tip - after this session, if you go to the native System Admin Profile, you can update the Default
Record Type to “User Story” so that you don’t have to select it for the next 2 weeks!

On your new User Story, populate the following fields:

1. Title: Company LinkedIn Page creation

2. Project: It is already linked to the project record we have just created in the previous step.
3. Org Credential: Dev1
4. Click on Save.
5. Open the User Story that you just created and notice that, although you did not populate the
Environment Dev1, it was automatically populated because of the Authenticated Org Credential you
selected
Exercise: Make Metadata Changes in Dev1
FROM THE USER STORY YOU JUST CREATED

1. Let’s see how we can leverage our Authenticated Org Credential to quickly log in to our Dev1 Sandbox, right from Copado
a. Right-click on your Org Credential “Dev1” and chose “Open in New Tab”
b. Confirm that your Org Credential still has the Green “Success: Credentials Validated” message at the top
2. Click on the “Open Org” button at the right side of the Org credential record page.

You should see that you have been automatically logged in to Dev1 Sandbox.

Let’s go into Setup → Object Manager → Account object → Fields & Relationships

Create a new URL Field:

1. Type: URL
2. Name: Company LinkedIn Page
3. Click “Next” and take All defaults all the way through to save

Once the field has been successfully created, go ahead and Logout of the Dev1 Sandbox and return to your User Story in Copado. If the Org
Credentials tab is still open, go ahead and close it to avoid tab-confusion.

Copado Tip - oftentimes, all of the Sandboxes on a Trial Org create on the same Server, so, in order to avoid cross-org pollination, I recommend
you always logout of a Sandbox, once you have finished Training Exercises in that Sandbox.
Exercise: Commit your Metadata Changes to the User Story
BACK ON YOUR USER STORY IN COPADO

Click on the “Commit Changes” button in the top right corner.

This is the Copado Commit Grid and I LOOOOVE IT!!!

Since we created the Company LinkedIn Page field after we authenticated our Org Credential, the field was not included in our original
metadata index, therefore, we need to refresh it. This should only take a moment.

The index only needs to be refreshed whenever you create a new metadata item AFTER the last index date (which can be checked by hovering
your pointer in the turning blue arrow).

If you only modified a component that was already indexed, then you don’t need to refresh the grid - Copado will always retrieve the current
available version of that component in that org (real-time retrieve).

Once the metadata refresh completes, let’s filter the Commit Grid to look for Name = linkedin and click the Select checkbox for our
Account.CompanyLinkedInPage custom field. (We will talk about Retrieve later in the Series).

Now click the “Commit Changes” button.

Exercise: Promote and Deploy the User Story to UAT
Copado has now committed our new custom field to a unique User Story Feature Branch in our Training Git
Repository, to be used for Deployment in a few moments, and it has also synched that new custom field to our
dev1 Environment Branch for Version Control.

Once the commit is done, check the “Promote & Deploy” checkbox on the User Story and save. This will
immediately start the deployment of this User Story up to our UAT Environment.

On the User Story’s “Related” tab, you will find the User Story Promotions Related List.

Chain out to Promotion (click on the P00* link), then scroll down and click on the Deployment record to monitor
progress; once the Deployment has “Completed Successfully,” return to your User Story and see how Copado
has automatically updated the Path and the Org Credential / Environment for UAT.
Homework to be completed before Session #2
Instead of developing each of the components to commit them into the User story, we are going to save a bit of time and use the following package which contains all of the
components we will need for Session #2.

1. Log into the Org where Copado is Installed

2. Go to the Org Credentials tab
3. Navigate to your Dev1 Org Credential
4. On your Dev1 Org Credential page, click on “Open Org”

This will log you into your Dev1 Org. You can check what environment you are by looking at the top of the page. In this case, you should see Dev1, the name of that
environment.

5. In the browser, paste the following link and click Enter:

https://test.salesforce.com/packaging/installPackage.apexp?p0=04t6g0000079vwbAAA

6. This package contains the following components:

a. Planet (Object)
b. Planet (Tab)
c. Planet (Layout)
d. AccountAutomations (Apex Class)
e. AccountAutomationsTest (Apex Class)

Note: The package can take some time to be installed. Be patient.

7. To check if the package has been installed, go to Setup

8. In the quick find field, type: “Installed packages”
9. The package name is: CPT-Commons
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