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

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!

‍

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.

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:

• Pre- and Post-Deployment Steps
• Seeding Sandboxes, Deploying Test Data and/or Deploying Data-as-Configuration-Data
• CI/CD Automation

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

‍