DevOps Center: A Swing and A Miss

After much runup and hype, Salesforce debuted DevOps Center at TDX ’22. It is incredible to release new software, especially with a behemoth of a platform like Salesforce, and even more so when reinventing a deployment tool such as change sets.

While this is an excellent option for those who want a free tool to replace change sets, it is far from ready for enterprise use. Since its release, blogs have touted its value. But few, if any, have shed constructive feedback or room for improvement.

The release will be in Public Beta this month with GA this fall. Salesforce declared that it will finish what it starts during the True to the Core at TDX, and let’s hope that is the case with DevOps Center because we cannot call it DevOps.

This release reminds me of the Workflow to Flow converter. The messaging is lacking; the converter was designed to easily translate your Workflows to Flows with the intent that you use Salesforce best practices to create larger flows where it makes sense. Many an Admin has used this converter as gospel, polluting their orgs with countless flows.

I am disappointed that the Salesforce Ecosystem hasn’t surfaced more about this product and the potential harm it can cause. DevOps is a tried and trued practice, and haphazardly introducing this product will cause friction between Admins and Engineering teams.

The Good

First, let’s focus on what DevOps Center got correct. The typical Salesforce design elements make a product relatively easy to use for less technical Admins.

User Interface

Those of us used to Salesforce’s interface will feel comfortable with the UI and Kanban view of DevOps Center.

It includes the familiar Path element, easily indicating where a feature or release is on its journey. This view reduces friction for Admins transitioning to a new way of thinking as a user can find elements easily.

Simplicity

Unlike some other release products that attempt to reinvent git within Salesforce, DOC steers clear of that concept. Leveraging source control to do what source control does best while displaying data and interacting with VCS through the Salesforce UI.

A focus and investment in ridding of Change Sets

This is a huge step forward. After so many years of Change Sets and a lack of a pipeline view for declarative — and, to an extent, programmatic — changes, the ecosystem has a new way of deploying changes. As this is just the beginning of the shift, we can hopefully see change sets be a thing of the past.

It’s Free

That’s right, as of the time of publication, DevOps Center will be a free SKU when it goes to General Availability. Those who have been in the ecosystem for a while know all too well the disappointment of getting hyped for a new feature, only to learn we have to carve out a section of our budget if we want it. We can now use this feature without needing to convince our CFO to hand over cash.

The Bad

Ultimately, the product leads to bad design patterns and, in a shocking twist, less automation. I’m concerned that this feature will lead to anti-patterns and a generation of Admins that don’t fully understand Version Control or what DevOps means to the rest of the industry.

Duplication of Effort

DOC is far from DRY. Work items (stories) highlight work but need to be manually created and are isolated from the cycles. For those using Jira or other ALMs to track their work, this is a duplication of effort.

We must go into our ticketing system of choice, manually move or update the elements, and, even worse, create the items in DevOps Center.

A true DevOps or CI/CD pipeline creates a unified ecosystem where work advances seamlessly without manual intervention. Disclaimer: there are partner apps that will do this for you with DevOps Center — but these contradict the free SKU.

GitHub Only

At the time of publication, DevOps Center only works with GitHub as a VCS, alienating those who use GitLab, Azure, or BitBucket.

In fairness, GitHub represents a large portion of the market share for VCS, and I am sure that Salesforce did its research here. But, its competitors currently can connect to the most popular VCS on the market to include all the above.

No Git Hooks

From what I can tell, there’s no ability to connect webhooks or git hooks to trigger different events in our pipeline.

The inability to introduce static code analyzers, trigger more extensive unit tests in another repo, or even notifications are something that shocks me.

In 2022, our VCS should be able to interact seamlessly with our pipeline.

Merge Conflicts Galore

There is no built-in mechanism to determine merge conflicts in the UI, resulting in multiple failures and overwriting metadata.

To resolve any potential merge conflicts, we must rely on the semantic layer of GitHub. XML can be challenging to read and a foreign concept to most Business Salesforce Admins. This will introduce complexity and frustration — especially if they do not have a Developer to call for help.

Secondarily, it does not appear that we can ignore reordering. This is critical as metadata can be randomized due to how Salesforce structures it.

No Back Promoting/Back Propagation

It’s a one-way street here, folks. We assume that everyone follows the development process and nothing unexpected happens. Promote something out of cycle? Congratulations, you have a lot of synchronization work ahead of you to get your branches in parity.

The lack of Back Propagation may have a tendency for Admins and Developers to skirt the process and cause quite a bit of drift between environments.

It’s best practice to have an escape hatch or a hotfix branch for emergencies that need to be introduced directly to Production (we never have bugs, right?).

Without back propagation, we are guaranteed to raise drift and eliminate the advantages of DevOps.

Easy to mess up GitHub Branches

If you don’t know what you’re doing, this can set a bad experience with GitHub. I envision the scenario where Admins get frustrated with DevOps due to merge conflicts and not to understand what is happening under the hood with their Pull Requests.

Due to the Merge Conflicts mentioned above, and no autodeletion of branches, I imagine repos that will become unmanageable over time.

Pay More Money Through Partners

Salesforce has left out some functionality such as integrations with ALMs — think Jira. Product Managers make tough decisions on what features to ship and ALM integration did not make the rough cut.

This is a bit disappointing, but partners have stepped in to fill this space, at an additional cost to the consumer.

We all appreciate the AppExchange. This is not a completely bad thing. Bringing partners into the ecosystem has made Salesforce great over the past 20 years.

However, core functionality that we expect in a tool called “DevOps Center” should be available at Day 0, not on the roadmap. DevOps instills a concept of more automation, not additional manual effort.

This product clearly has potential, but Salesforce arrived far short of expectations. Salesforce has been pounding the DevOps drum through press lately, but this product needed to bake further.

I am disappointed that Salesforce didn’t attempt to acquihire in this space and build their own product.

I hope that Salesforce continues to invest in the product and pushes more through the next release, as this sets a bad precedent for those new to DevOps. This can develop bad habits for solo admins or admins without DevOps or CI/CD experience.

Perhaps if Salesforce wasn’t chasing trends such as NFT, we would see a better core product that affects all clouds.

Originally published at https://mattpieper.com on June 18, 2022.