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

April 30, 2020

Team Copado

Authored by Jen Nelson | Senior Solution Consultant | Copado

Hello, #AwesomeAdmins!

In our last conversations, Why Change Sets Suck (the Time out of your DevOps Process) – Part 1 and Why Change Sets Suck (the Time out of your DevOps Process) – Part 2, we looked at the limitations of native Change Sets solved by Copado including Version Control, Release Pipeline structure and cross-Stack Deployments, Deploying Standard Components, Standard Settings and Custom Settings with Values and Quality Control.

As mentioned previously, there are many limitations to native Change Sets, and Copado resolves all of them!

In Part 3 of our 3-Part Series, we are going to focus on Pre- and Post-Deployment Steps, Seeding Sandboxes, Deploying Test Data and/or Deploying Data-as-Configuration-Data and CI/CD Automation.

Native Change Sets do NOT allow Pre- and Post-Deployment Steps

Native Change Sets simply Deploy Metadata Changes from one Salesforce Environment to another.

Any additional Pre- and Post-Deployment Steps required must be tracked and executed outside of Salesforce.

Copado includes a wide array of Pre- and Post-Deployment Steps

The Deployment Steps can be added to a User Story as a Pre- or Post-Deployment Task or can be added directly to a Deployment record.

Here are just a few examples:

Keep track of your Pre- and Post-Deployment Manual Tasks and get record of completion within the Deployment history
Deploy Data alongside your Metadata Changes using either simple Data Soql Queries for basic, single-object Data Deployment or the Copado Advanced Data Deployer’s Data Templates for complex, multi-object Data Deployment
Run Apex Scripts, for example, to Freeze Active Users Pre-Deployment, then a second Deployment Task to Unfreeze those Users Post-Deployment
Run a Webhook URL Callout, for example to invoke a Pre- or a Post-Deployment Git Snapshot
Run an External CI Job, for example to Jenkins or Bamboo, in order to spark a 3rd-party Regression Testing Platform

Native Change Sets do NOT allow Seeding of Sandboxes, nor Deployment of Test Data or Data-Used-as-Configuration-Data

Whether you desire to seed a Developer Sandbox, DevPro Sandbox or PartialCopy Sandbox or you need to Deploy Test Data or Data-Used-as-Configuration-Data alongside your Metadata Changes, for example, with Applications such as CPQ, Field Service Lightning, Vlocity or Ncino, there is no mechanism in native Change Sets to Deploy Data.

Copado’s Advanced Data Deployer

Copado’s Add-on Module, Advanced Data Deployer (ADD) supports both Use Cases – Seeding of Sandboxes and Deployment of Data-Used-as-Configuration-Data through the use of multi-object JSON-based Data Templates.

See the Copado Advanced Data Deployer in action!

Copado’s Vlocity Integration

Copado’s Vlocity Integration allows the selection of Vlocity Configurations in the same Commit Metadata Grid as your Salesforce Metadata Changes.

The selected Vlocity Configurations will commit to the User Story Feature Branch in Git.

User Story Feature Branch in Git - Copado

Native Change Sets do NOT allow for any CI / CD Automation

As noted earlier, no Sequencing of native Deployment Connections can be created nor enforced, and, additionally, no CI / CD Automation can be added to native Deployment Connections and native Change Sets.

Copado Continuous Delivery (CCD)

By leveraging native Change Data Capture on User Stories and Promotions, Copado Continuous Delivery allows Copado Customers to grow into increasing levels of Continuous Integration and Continuous Delivery as your DevOps Process matures through an enhanced Pipeline Page and Pipeline Configuration, including CCD Connection Behaviors and CCD Quality Gates for your Metadata Groups.

Check out this Demo of Copado Continuous Delivery to see it in action!