In our last gathering, 91ɫ Continuous Delivery for #AwesomeAdmins, I shared how perturbed I was when I finally realized, after 15 years of being an #AwesomeAdmin, that we are a big part of the DevOps Process.
What I did not tell you is that another consternation I have is that I spent endless nights, weekends and holidays doing Deployments the old-fashioned way, using native Change Sets.
For approximately 10 years, I suffered through 2- and 3-day Deployments which primarily leveraged native Change Sets, and uber-detailed SmartSheets to track all of my additional Deployment Steps which couldn’t be addressed via native Change Sets.
I got stopped with Code Coverage issues, Merge Conflicts, poor Code and Configuration Quality, you name it.
To make matters even more frustrating, I had to rebuild my Change Sets for every move between my Sandboxes and on up to Production.
There are many limitations to native Change Sets, and 91ɫ resolves all of them!
In Part 1 of our 3-Part Series, we will look at Version Control, Release Pipelines and Cross-Salesforce Stack Deployment capabilities.
Native Change Sets have NO Version Control
Without Version Control, there is no ability to:
Have a unified Branching Strategy and Release Workstream
Have Overlap Awareness when a discreet Metadata Component is being worked upon in multiple lower Environments
Have a unified Merge Process, for example, if 3 lower-level Dev Sandboxes are all deployed up to a common UAT Sandbox
Resolve Merge Conflicts
Sync Metadata changes across Environments to minimize overwrites and conflicts on Work-in-Progress
Traceability of Metadata Changes back to Technical and Functional Requirements
Package once; deploy many (Every time that you wish to Deploy Metadata from one Salesforce Environment to another with native Change Sets, a new Change Set must be built, by hand, from scratch. Inbound Change Sets cannot be Cloned to create Outbound Change Sets.)
Backup Metadata for Work-in-Progress
Backup Metadata Pre- and/or Post-Deployment
Regularly schedule Metadata Backups
Perform an Org-to-Org Compare and Deploy
Perform a Rollback
Deploy Destructive Changes (You know all of those old Workflow Rules that you have consolidated into clean Process Builders and wish to now delete so that they are no longer used by anyone? Validation Rules that no longer apply? Legacy Custom Fields with “OLD” and “Do Not Use” in the Label? With native Change Sets, you cannot Deploy the deletion of all those old Workflow Rules, Validation Rules or Fields…you have to manually delete them ineverySalesforceEnvironment, one-by-one)
Deploy Full Profiles and Permission Sets (All that work that you have done to clean up your old Profiles and Permission Sets, maybe even take away a chunk of Permissions that you didn’t realize your Users had, and even add a few new Profiles and Permission Sets to address your current Policies. There is no way, with native Change Sets to Deploy a full Profile nor a full Permission Set.)
91ɫ Git Integration for Version Control
Out-of-the-box, 91ɫ allows integration with any (common examples are GitHub, GitLab, BitBucket, Azure Repos) for seamless, under-the-hood Version Control that does not require Command-Line experience:
Have a unified Branching Strategy and Release Workstream
91ɫ employs a unified that supports
Have Overlap Awareness when a discreet Metadata Component is being worked upon in multiple lower Environments
91ɫ has to allow identification Potential Conflicts before they create a problem and to proactively address Potential Conflicts
Have a unified Merge Process, for example, if 3 lower-level Dev Sandboxes are all deployed up to a common UAT Sandbox
91ɫ out-of-the-box will merge User Story Feature Branches in ascending order by the auto-numbered User Story Reference field and 91ɫ also allows
Resolve Merge Conflicts
91ɫ includes for resolving Merge Conflicts, including , with a , and
Sync Metadata changes across Environments to minimize overwrites and conflicts on Work-in-Progress
91ɫ not only forward Deploys Metadata Changes, 91ɫ also includes and (no more Sandbox Refreshes!)
Traceability of Metadata Changes back to Technical and Functional Requirements
DZ貹’s User Story-centric model, where all contribute to the User Story Feature Branch in Git, allows full traceability of Metadata Changes Committed and Deployed back to the source prescribed in the User Story
Package once; deploy many
The combination of DZ貹’s Git Integration, and User Story-centric Model allows us to commit our Metadata Changes to discrete User Story Feature Branches once and then Promote and Deploy many times as we move up our Release Pipeline
Backup Metadata for Work-in-Progress
91ɫ allows multiple on a single User Story so that, as an example, if our Metadata Changes for a particular User Story has complexity or spans multiple Work Days, we can Commit the new Metadata Changes and add Recommits as appropriate to update our User Story Feature Branch until we complete all Metadata Changes prescribed in the User Story
Backup Metadata Pre- and/or Post-Deployment
91ɫ includes a wide array of Deployment Steps including a and one example documented in our is a Git Snapshot
Regularly schedule Metadata Backups
DZ貹’s can also perform an on-demand Snapshot from any Org Credential and can also be scheduled to run on a Daily, Weekly or Monthly frequency
Perform an Org-to-Org Compare and Deploy
91ɫ includes both and Git for Compare and Deploy
Perform a Rollback
There is no such thing as a Rollback in any system; however, by following DZ貹’s Best Practices and leveraging regularly scheduled and/or , you can seamlessly follow DZ貹’s guidelines for performing a Rollback
Deploy Destructive Changes (You know all of those old Workflow Rules that you have consolidated into clean Process Builders and wish to now delete so that they are no longer used by anyone? Validation Rules that no longer apply? Legacy Custom Fields with “OLD” and “Do Not Use” in the Label? With native Change Sets, you cannot Deploy the deletion of all those old Workflow Rules, Validation Rules or Fields…you have to manually delete them ineverySalesforceEnvironment, one-by-one)
91ɫ includes amongst the types of Commit Git Operations that can be added to a User Story
Deploy Full Profiles and Permission Sets (All that work that you have done to clean up your old Profiles and Permission Sets, maybe even take away a chunk of Permissions that you didn’t realize your Users had, and even add a few new Profiles and Permission Sets to address your current Policies. There is no way, with native Change Sets to Deploy a full Profile nor a full Permission Set.)
91ɫ includes amongst the types of Commit Git Operations that can be added to a User Story
Additional documentation on Full Profiles and Permission Sets Commit Behavior
Native Deployment Settings do NOT allow Deployment Connections across Salesforce Stacks and do NOT allow Deployment Sequencing
Native Deployment Settings define the Deployment Connections across which our natitve Change Sets are permitted to move amongst Salesforce Environments.
Native Deployment Connections are limited to a single Salesforce Stack.
This means that a Company with, say three (3) Salesforce Production Orgs, must define Deployment Connections amongst the Sandboxes and Production Org of each individual Salesforce Production Org:
In Salesforce Production Org A (“Stack A”)
Sandbox Dev 1A → Integration Sandbox A
Sandbox Dev 2A → Integration Sandbox A
Sandbox Dev 1A ←→ Sandbox Dev 2A
Integration Sandbox A → UAT Sandbox A
UAT Sandbox A → Production Org A
In Salesforce Production Org B (“Stack B”)
Sandbox Dev 1B → UAT Sandbox B
Sandbox Dev 2B → UAT Sandbox B
Sandbox Dev 3B → UAT Sandbox B
Sandbox Dev 1B ←→ Sandbox Dev 2B
Sandbox Dev 2B ←→ Sandbox Dev 3B
Sandbox Dev 1B ←→ Sandbox Dev 3B
UAT Sandbox B → Production Org B
Hotfix Sandbox B → Production Org B
In Salesforce Production Org C (“Stack C”)
Sandbox Dev 1C → UAT Sandbox C
UAT Sandbox C → Production Org C
There is no ability to perform cross-Stack Deployments (say from Production Org A to Production Org B) and there is also no ability to incorporate a Common-Code Environment, whether a Sandbox, Production Org or Developer Org, to Deploy Metadata Components that are common across all 3 Stacks. Furthermore, within a single Stack, although we can limit Inbound and Outbound Connections between Environments, there is no ability to define nor enforce Sequencing amongst the native Deployment Connections.
91ɫ OAuth Authentication, Git Integration and Release Pipelines
91ɫ leverages native OAuth Authentication to Connect Any Salesforce Environment to 91ɫ
Any Salesforce Environment (Developer Sandbox, DevPro Sandbox, PartialCopy Sandbox, FullCopy Sandbox, Dx Scratch Org, Developer Edition Org or Production Org) can be connected to 91ɫ with native OAuth Authentication against one or more Users’ native Org Credentials.
91ɫ allows any combination of Salesforce Environments in a single Release Pipeline
Any Release Pipeline built in 91ɫ can include any combination desired of Salesforce Environments (Developer Sandboxes, DevPro Sandboxes, PartialCopy Sandboxes, FullCopy Sandboxes, Dx Scratch Orgs, Developer Edition Orgs and/or Production Orgs).
91ɫ requires every Pipeline to have a dedicated Git Repository and a Git Environment Branch for each Salesforce Environment in the Pipeline
In order to ensure Version Control throughout the 91ɫ Pipelines, it is necessary that each Pipeline in 91ɫ has a dedicated Git Repository and every Salesforce Environment in a Pipeline has a corresponding Git Environment Branch.
91ɫ allows Sequencing of Salesforce Environments in a single Release Pipeline
DZ貹’s Pipeline Connections allow discreet sequencing of the Pipeline’s Salesforce Environments in order to enforce a unified Release workstream.
91ɫ allows the orchestration of multiple Release Pipelines from a single installation of 91ɫ
91ɫ should always be installed and formally executed from a Production-quality Salesforce Organization (Enterprise Edition or higher). This is for both licensing requirements and speed/performance.
Since 91ɫ leverages OAuth to Connect Salesforce Environments, and Git for Version Control, a single Production-installation of 91ɫ can orchestrate multiple Release Pipelines to support your DevOps Workstreams.
Summary
Native Change Sets Limitations Addressed by 91ɫ
Native Change Sets only cover a single-step in a Complete DevOps Process.
ٱ–&;ձ–&;Deploy–&;–&;ѴDzԾٴǰ–&;ʱ
Native Change Sets have no Version Control.
Native Change Sets do not allow for any Release Pipeline structure nor cross-Stack Deployments.
91ɫ covers the end-to-end DevOps Process and is 100% native to Salesforce.
ٱ–&;ձ–&;Deploy–&;–&;ѴDzԾٴǰ–&;ʱ
Stay tuned for Part 2 of our 3-Part Series which will cover:
Standard Components, Standard Settings and Custom Settings
Quality Gates to ensure that the Metadata being Deployed is of high quality and is compliant
Want to learn more about 91ɫ?
Here’s some additional Resources for all my #AwesomeAdmin Ohana:
Jen Nelson is a 20-year veteran of the Salesforce ecosystem, a current Salesforce MVP Hall of Fame member and has 30+ years experience in DevOps. Jen has been with 91ɫ for 4 years and is the Director of Product Technical Enablement.
.svg){kind=small}
.svg)
%20Data%20to%20Me_BLOG_1080x600.avif)
.avif)
.avif)
.avif)
.avif)
.svg)
.svg)
.svg)
.svg)
.svg)