.svg){kind=small}
.svg)
.avif)
.avif)
.avif)
No items found.
言語
Articles
6/4/2020
10 minutes
Why Change Sets Suck (the Time out of your DevOps Process) – Part 3
.svg)
.svg)
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 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.
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:
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 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 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.
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.
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!
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
Here’s some additional Resources for all my #AwesomeAdmin Ohana:
.svg)
.svg)
.svg)