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

April 24, 2020

Team Copado

Authored by Jen Nelson | Senior Solution Consultant | Copado

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.

Native Change Sets do NOT include Standard Metadata

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.

Copado uses the Salesforce Metadata API and all Supported Metadata

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!

Copado uses the Salesforce Metadata API and all Supported Metadata

Gone are the days of having to manually track and update:

Changes to Standard (native) Page Layouts
Changes to Standard (native) Fields
Changes to Standard (native) ValueSets; examples of StandardValueSet would be the Type or Industry Picklist Values on the Account Object
Changes to Standard (native) List Views
Changes to Standard (native) Lookup Filters
Changes to Standard (native) Search Layouts

Native Change Sets do NOT include Custom Settings Values

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:

**Copado will Commit Custom Settings Metadata and Deploy Custom Settings Values**

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!

Native Change Sets do NOT include any Standard Settings

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.

Copado’s Metadata Grid supports all Metadata supported by the Salesforce Metadata API – including Standard Settings

With the Copado Metadata Grid, all Standard Settings in the Salesforce Metadata API are available for selection.

Native Change Sets do NOT include any Quality Control of Metadata Changes Deployed that is not natively required by the Platform

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 includes extensive Quality Gates

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

Apex Tests with Code Coverage – bonus, Copado allows us to set Minimum Code Coverage Thresholds for each Salesforce Environment in our Release Pipelines
Validation-only Deployments
Native Salesforce Automations (SFA) including Approval Processes, Validation Rules, Workflows, Process Builders/Flows and Rollup Summaries, to name a few

Out-of-the-Box Quality Gates

Static Code Analysis for Apex Best Practices via either
- the free PMD Rule Set
- an out-of-the-box integration to your own paid instance of CodeScan / SonarQube
Pull Requests for Peer Review
Manual “Smoke Tests” for User Acceptance Testing

Add-on Quality Gates

Copado Selenium Testing – Automated Selenium Regression Testing on Platforms such as Sauce Labs, BrowserStack or Cross Browser Testing
Copado Compliance Hub – a custom Rules Engine to scan key Metadata Components such as Profiles or Permission Sets for violations such as View All Data/Modify All Data being exposed to Non-System Administrator Profiles

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.
Copado covers the end-to-end DevOps Process and is 100% native to Salesforce.