.svg){kind=small}
.svg)
.avif)
.avif)
.avif)
No items found.
言語
Articles
4/30/2020
10 minutes
Why Change Sets Suck (the Time out of your DevOps Process) – Part 2
.svg)
.svg)
Hello, #AwesomeAdmins!
In our last post, Why Change Sets Suck (the Time out of your DevOps Process) – Part 1, we looked at the limitations of native Change Sets solved by Copado including Version Control, Release Pipeline structure and cross-Stack Deployments.
As mentioned previously, there are many limitations to native Change Sets, and Copado resolves all of them!
In Part 2 of our 3-Part Series, we are going to focus on Deploying Standard Components, Standard Settings,Custom Settings with Values and Quality Control.
When searching for Metadata Components to add to a native Change Set, there are no Standard Metadata Components available for Selection.
That means, for example, any changes that you have made to Standard Fields, including modification of Standard Value Sets, as well as Standard Layouts, Standard List Views and Standard Objects cannot be included in a native Change Set.
Instead, you must manually track these Standard Metadata Component changes and manually update each Salesforce Environment accordingly.
Any Metadata Component supported by the Salesforce Metadata API is available for selection in the Copado Metadata Grid on Commits and Deployments.
Notice in the Copado Metadata Grid example shown below how none of the Components that I have selected have __c at the end of the Component Name…that means that everything I have selected below is a Standard Component!
Gone are the days of having to manually track and update:
While a native Change Set does allow us to select a Custom Setting and the Custom Setting’s Metadata:
We are only able to retrieve the Metadata, not the actual Values that we have defined behind the Custom Settings’ “Manage” button:
With Copado, we can not only select the Custom Settings Metadata in our out-of-the-box Metadata Grid:
But we can also add a Deployment Task (aka Deployment Step) of Type “Custom Setting” to our User Story, so that we retrieve the Custom Settings Values we have defined in “Manage”:
No more having to track our Custom Settings Values manually and no more having to manually update each Salesforce Environment with our Custom Settings Values!
With native Change Sets, you will need to manually track any changes you make to all Standard Settings and you will need to manually update those Standard Settings in each Environment as you move up your Release Pipeline:
As of this writing, Salesforce’s Generally Available API is v47 (Winter ‘20) with v48 (Spring ‘20) in Preview Sandboxes.
Depending on your Salesforce Edition, as well as Features enabled in your Orgs, there are potentially 90+ Standard Settings included in the Salesforce Metadata API and, if any of these 90+ Standard Settings were changed as part of your DevOps Process, you are unable to include these Standard Settings in native Change Sets and would, instead, have to manually track and update these Standard Settings on each Salesforce Environment.
With the Copado Metadata Grid, all Standard Settings in the Salesforce Metadata API are available for selection.
The only quasi-Quality Controls available in native Change Sets are the native Salesforce Platform-required Apex Tests with Code Coverage and Validation-only Deployments.
The only quasi-Quality Controls available in native Change Sets are the native Salesforce Platform-required Apex Tests with Code Coverage and Validation-only Deployments.
Copado Quality Gates can be run from User Stories, but oftentimes can also be run from an Org Credential to include a complete Environment (on-demand or as a Scheduled Job), or as Quality Gates in Copado Continuous Delivery.
Native Salesforce Quality Gates
Out-of-the-Box Quality Gates
Add-on Quality Gates
Create–>Test–>Deploy–>Release–>Monitor–>Plan
Learn more about Copado’s Solutions By DevOps Stage.
Stay tuned for Part 3 of our 3-Part Series which will cover:
Here’s some additional Resources for all my #AwesomeAdmin Ohana:
.svg)
.svg)
.svg)