Professional Documents
Culture Documents
Copado Partner Success Training #1 - Copado Overview and Setup
Copado Partner Success Training #1 - Copado Overview and Setup
Training Webinars
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
Go-Live Gap
PLAN MONITOR
"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
Native Experience
DEVELOPER ARCHITECT
Prebuilt Integrations
INNOVATION DELIVERY PERFORMANCE
➔ Leverage the Underlying Platform that you Know Complete CI/CD Processes
Dev 1
Dev 2
Backend infrastructure to
support heavy lifting operations
and scale at trust
Note: The user that was used to install the package is already added to the list.
Step 2: Assign the “Copado User” Permission Set
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)
Now, you should see your new Org Credential under “Existing Org Credentials”
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.
● 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.
● 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.
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.
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.
Click the “New Pipeline” button and Populate the following fields:
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.
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.
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!
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
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
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).
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.
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.
https://test.salesforce.com/packaging/installPackage.apexp?p0=04t6g0000079vwbAAA
Nolan Larrabee
Sales Engineer
Dayton, OH