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

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.

‍

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!

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.

Native Change Sets do not allow inclusion of any Standard Components, Standard Settings nor Custom Settings.

Native Change Sets have no Quality Gates to ensure that the Metadata being Deployed is of high quality and is compliant.

Native Change Sets neither include nor spark any Pre- or Post-Deployment Steps, so they must be tracked manually in spreadsheets and documents.

Native Change Sets do not Deploy Data.

Native Change Sets have no CI / CD Automation.

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

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

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

‍