Why Change Sets Suck (the Time out of your DevOps Process) – Part 1

Hello, #AwesomeAdmins! 

In our last gathering, Copado Continuous Delivery for #AwesomeAdmins, I shared how perturbed I was when I finally realized, after 15 years of being an #AwesomeAdmin, that we are a big part of the DevOps Process.

What I did not tell you is that another consternation I have is that I spent endless nights, weekends and holidays doing Deployments the old-fashioned way, using native Change Sets.

For approximately 10 years, I suffered through 2- and 3-day Deployments which primarily leveraged native Change Sets, and uber-detailed SmartSheets to track all of my additional Deployment Steps which couldn’t be addressed via native Change Sets.  

I got stopped with Code Coverage issues, Merge Conflicts, poor Code and Configuration Quality, you name it.

To make matters even more frustrating, I had to rebuild my Change Sets for every move between my Sandboxes and on up to Production.

There are many limitations to native Change Sets, and Copado resolves all of them!

In Part 1 of our 3-Part Series, we will look at Version Control, Release Pipelines and Cross-Salesforce Stack Deployment capabilities.

Native Change Sets have NO Version Control

Without Version Control, there is no ability to:

• Have a unified Branching Strategy and Release Workstream
• Have Overlap Awareness when a discreet Metadata Component is being worked upon in multiple lower Environments
• Have a unified Merge Process, for example, if 3 lower-level Dev Sandboxes are all deployed up to a common UAT Sandbox
• Resolve Merge Conflicts
• Sync Metadata changes across Environments to minimize overwrites and conflicts on Work-in-Progress
• Traceability of Metadata Changes back to Technical and Functional Requirements
• Package once; deploy many (Every time that you wish to Deploy Metadata from one Salesforce Environment to another with native Change Sets, a new Change Set must be built, by hand, from scratch. Inbound Change Sets cannot be Cloned to create Outbound Change Sets.)
• Backup Metadata for Work-in-Progress
• Backup Metadata Pre- and/or Post-Deployment
• Regularly schedule Metadata Backups
• Perform an Org-to-Org Compare and Deploy
• Perform a Rollback
• Deploy Destructive Changes (You know all of those old Workflow Rules that you have consolidated into clean Process Builders and wish to now delete so that they are no longer used by anyone?  Validation Rules that no longer apply? Legacy Custom Fields with “OLD” and “Do Not Use” in the Label? With native Change Sets, you cannot Deploy the deletion of all those old Workflow Rules, Validation Rules or Fields…you have to manually delete them in every Salesforce Environment, one-by-one)

Deploy Full Profiles and Permission Sets (All that work that you have done to clean up your old Profiles and Permission Sets, maybe even take away a chunk of Permissions that you didn’t realize your Users had, and even add a few new Profiles and Permission Sets to address your current Policies.  There is no way, with native Change Sets to Deploy a full Profile nor a full Permission Set.)

Copado Git Integration for Version Control

Out-of-the-box, Copado allows integration with any Git Provider (common examples are GitHub, GitLab, BitBucket, Azure Repos) for seamless, under-the-hood Version Control that does not require Command-Line experience:

• Have a unified Branching Strategy and Release Workstream
• Copado employs a unified Branching Strategy that supports multiple workstreams
• Have Overlap Awareness when a discreet Metadata Component is being worked upon in multiple lower Environments
• Copado has User Story Overlap Awareness to allow identification Potential Conflicts before they create a problem and Pull Requests to proactively address Potential Conflicts
• Have a unified Merge Process, for example, if 3 lower-level Dev Sandboxes are all deployed up to a common UAT Sandbox
• Copado out-of-the-box will merge User Story Feature Branches in ascending order by the auto-numbered User Story Reference field and Copado also allows Override of the User Story Promotion Merge Order
• Resolve Merge Conflicts
• Copado includes multiple options for resolving Merge Conflicts, including Auto-Resolution, Online Conflict Resolution with a Merge Conflict Resolution Panel, and Smart Conflict Resolution  
• Sync Metadata changes across Environments to minimize overwrites and conflicts on Work-in-Progress
• Copado not only forward Deploys Metadata Changes, Copado also includes Back Promotion and Mass Back Promotion (no more Sandbox Refreshes!)
• Traceability of Metadata Changes back to Technical and Functional Requirements
• Copado’s User Story-centric model, where all Commits contribute to the User Story Feature Branch in Git, allows full traceability of Metadata Changes Committed and Deployed back to the source Technical and Functional Specifications/Requirements prescribed in the User Story
• Package once; deploy many
• The combination of Copado’s Git Integration, Branching Strategy and User Story-centric Model allows us to commit our Metadata Changes to discrete User Story Feature Branches once and then Promote and Deploy many times as we move up our Release Pipeline
• Backup Metadata for Work-in-Progress
• Copado allows multiple Commits on a single User Story so that, as an example, if our Metadata Changes for a particular User Story has complexity or spans multiple Work Days, we can Commit the new Metadata Changes and add Recommits as appropriate to update our User Story Feature Branch until we complete all Metadata Changes prescribed in the User Story
• Backup Metadata Pre- and/or Post-Deployment
• Copado includes a wide array of Deployment Steps including a Webhook URL Callout and one example documented in our Webhook Library is a Git Snapshot
• Regularly schedule Metadata Backups
• Copado’s Git Snapshot can also perform an on-demand Snapshot from any Org Credential and can also be scheduled to run on a Daily, Weekly or Monthly frequency
• Perform an Org-to-Org Compare and Deploy
• Copado includes both Org Differences and Git Snapshot Differences for Compare and Deploy
• Perform a Rollback
• There is no such thing as a Rollback in any system; however, by following Copado’s Best Practices and leveraging regularly scheduled Git Snapshot and/or Git Snapshots via a Pre- or Post-Deployment Step for Webhook URL Callout, you can seamlessly follow Copado’s guidelines for performing a Rollback
• Deploy Destructive Changes (You know all of those old Workflow Rules that you have consolidated into clean Process Builders and wish to now delete so that they are no longer used by anyone?  Validation Rules that no longer apply? Legacy Custom Fields with “OLD” and “Do Not Use” in the Label? With native Change Sets, you cannot Deploy the deletion of all those old Workflow Rules, Validation Rules or Fields…you have to manually delete them in every Salesforce Environment, one-by-one)
• Copado includes Destructive Changes amongst the types of Commit Git Operations that can be added to a User Story
• Deploy Full Profiles and Permission Sets (All that work that you have done to clean up your old Profiles and Permission Sets, maybe even take away a chunk of Permissions that you didn’t realize your Users had, and even add a few new Profiles and Permission Sets to address your current Policies.  There is no way, with native Change Sets to Deploy a full Profile nor a full Permission Set.)
• Copado includes Full Profiles and Permission Sets amongst the types of Commit Git Operations that can be added to a User Story
• Additional documentation on Full Profiles and Permission Sets Commit Behavior

Native Deployment Settings do NOT allow Deployment Connections across Salesforce Stacks and do NOT allow Deployment Sequencing

Native Deployment Settings define the Deployment Connections across which our natitve Change Sets are permitted to move amongst Salesforce Environments.

Native Deployment Connections are limited to a single Salesforce Stack.

This means that a Company with, say three (3) Salesforce Production Orgs, must define Deployment Connections amongst the Sandboxes and Production Org of each individual Salesforce Production Org:

In Salesforce Production Org A (“Stack A”)

• Sandbox Dev 1A → Integration Sandbox A
• Sandbox Dev 2A → Integration Sandbox A
• Sandbox Dev 1A ←→ Sandbox Dev 2A
• Integration Sandbox A → UAT Sandbox A
• UAT Sandbox A → Production Org A

In Salesforce Production Org B (“Stack B”)

• Sandbox Dev 1B → UAT Sandbox B
• Sandbox Dev 2B → UAT Sandbox B
• Sandbox Dev 3B → UAT Sandbox B
• Sandbox Dev 1B ←→ Sandbox Dev 2B
• Sandbox Dev 2B ←→ Sandbox Dev 3B
• Sandbox Dev 1B ←→ Sandbox Dev 3B
• UAT Sandbox B → Production Org B
• Hotfix Sandbox B → Production Org B

In Salesforce Production Org C (“Stack C”)

• Sandbox Dev 1C → UAT Sandbox C
• UAT Sandbox C → Production Org C

There is no ability to perform cross-Stack Deployments (say from Production Org A to Production Org B) and there is also no ability to incorporate a Common-Code Environment, whether a Sandbox, Production Org or Developer Org, to Deploy Metadata Components that are common across all 3 Stacks.  Furthermore, within a single Stack, although we can limit Inbound and Outbound Connections between Environments, there is no ability to define nor enforce Sequencing amongst the native Deployment Connections.

Copado OAuth Authentication, Git Integration and Release Pipelines

Copado leverages native OAuth Authentication to Connect Any Salesforce Environment to Copado

Any Salesforce Environment (Developer Sandbox, DevPro Sandbox, PartialCopy Sandbox, FullCopy Sandbox, Dx Scratch Org, Developer Edition Org or Production Org) can be connected to Copado with native OAuth Authentication against one or more Users’ native Org Credentials.

Copado allows any combination of Salesforce Environments in a single Release Pipeline

Any Release Pipeline built in Copado can include any combination desired of Salesforce Environments (Developer Sandboxes, DevPro Sandboxes, PartialCopy Sandboxes, FullCopy Sandboxes, Dx Scratch Orgs, Developer Edition Orgs and/or Production Orgs).

Copado requires every Pipeline to have a dedicated Git Repository and a Git Environment Branch for each Salesforce Environment in the Pipeline

In order to ensure Version Control throughout the Copado Pipelines, it is necessary that each Pipeline in Copado has a dedicated Git Repository and every Salesforce Environment in a Pipeline has a corresponding Git Environment Branch.

Copado allows Sequencing of Salesforce Environments in a single Release Pipeline

Copado’s Pipeline Connections allow discreet sequencing of the Pipeline’s Salesforce Environments in order to enforce a unified Release workstream.

‍

‍

Copado allows the orchestration of multiple Release Pipelines from a single installation of Copado

Copado should always be installed and formally executed from a Production-quality Salesforce Organization (Enterprise Edition or higher).  This is for both licensing requirements and speed/performance. 

Since Copado leverages OAuth to Connect Salesforce Environments, and Git for Version Control, a single Production-installation of Copado can orchestrate multiple Release Pipelines to support your DevOps Workstreams.

‍

Summary

Native Change Sets Limitations Addressed by Copado

Native Change Sets only cover a single-step in a Complete DevOps Process.

Create–>Test–>Deploy–>Release–>Monitor–>Plan

Native Change Sets have no Version Control.

Native Change Sets do not allow for any Release Pipeline structure nor cross-Stack Deployments.

Copado covers the end-to-end DevOps Process and is 100% native to Salesforce.

Create–>Test–>Deploy–>Release–>Monitor–>Plan 

Stay tuned for Part 2 of our 3-Part Series which will cover:

• Standard Components, Standard Settings and Custom Settings
• Quality Gates to ensure that the Metadata being Deployed is of high quality and is compliant

Want to learn more about Copado?

Here’s some additional Resources for all my #AwesomeAdmin Ohana:

• Get a Demo
• Follow us on LinkedIn, Twitter, YouTube and Facebook

Want to join the Team?

• Apply on LinkedIn or via Copado → Careers

‍