Is DevOps Center going to kill all other Salesforce DevOps vendors?
With the rise of sfdx, creating your own CI/CD pipeline has become more accessible, especially when free tools are available to help.
This has led to a "Build vs. Buy" debate over the last couple of years: Should you build your own CI/CD pipeline or buy off-the-shelf software like Salto, Copado, or Gearset?
The debate made sense because those were your only options; either you build it yourself or buy it. The 3rd option was to use Change Sets, but they don't really enable anything close to CI/CD, so it was never considered a real option.
The debate is more complex now that DevOps Center has become generally available. Now, there's a third option perfect for those who don't want to build and don't want to buy: Use Salesforce's provided CI/CD tool.
This poses an interesting question:
Read on to find out...
When to use DevOps Center
Naturally, most of us will want to start (emphasis on start) our DevOps journey with DevOps Center. Here are the reasons why:
It's free
At the time of this writing, DevOps Center is free. That may change at some point in the future, but using a free tool created by Salesforce is a very attractive value proposition.
It's fully supported by Salesforce
Unlike using your own CI/CD tool, Salesforce will support you along the way. If you have questions, issues, or bugs while using DevOps Center, you can simply log a case with Salesforce Support and expect a reply according to their SLAs.
You cannot do this with your own tool, and support may vary from one DevOps vendor to another.
It has a rich roadmap
Salesforce has published the DevOps Center roadmap, with many features to look forward to. We also benefit from being able to submit ideas on the idea exchange or directly on GitHub.
That said, you are limited to what DevOps Center can do. If you want more flexibility, you may need something else; this leads us to the next section.
When to build your own CI/CD pipeline
Building your own CI/CD pipeline makes sense when:
You want full control of everything
With a custom CI/CD pipeline, you control everything. You can decide:
- When to deploy
- from which branches
- whether to use delta vs. full deployment
- Whether to use static code analysis
- Deploy only specific folders within your sfdx project (modular development)
- Automatically create scratch orgs and deploy changes to them
- etc
Almost anything you can think you can be done with a custom CI/CD pipeline. For example, you can create scripts to enable flows automatically after they are deployed to production.
You can also write scripts to run apex tests based on the data in a pull request.
Pablo Gonzalez
In short, the possibilities are endless. This, however, comes with a cost: You need deep expertise in a wide variety of technologies to support your pipeline.
The skills required to maintain a CI/CD pipeline don't come naturally to most Salesforce developers/architects, and it's a long learning curve.
A custom CI/CD pipeline also doesn't address other issues, such as deploying reference data, being able to do impact analysis before deployment (to understand deployment dependencies), etc.
Is there a future for DevOps Vendors?
As I said at the beginning of the article, the release of DevOps Center puts DevOps vendors in a challenging position. It's natural to wonder if the business of creating DevOps platforms will slowly die.
Here's my take on it:
Been there done that
Just because there's a salesforce-supported, free way to do something doesn't mean it's the best way or that there's no room for some healthy competition.
Many apps on the Appexchange compete with Salesforce's native functionality. So, for example, there are apps for CPQ that compete with Salesforce CPQ. There are apps for creating better UIs that compete with some of the capabilities of LWC, etc. So in that sense, this situation we found ourselves in is nothing new.
Forced evolution
With the rise of DevOps Center, DevOps vendors will now be forced to provide capabilities beyond simple deployments from one org to another.
Here are some of the capabilities that DevOps vendors will need to consider to stay competitive:
- Ability to deploy CPQ data alongside metadata
- Impact analysis before and during deployment
- Hybrid model: the ability to add custom scripts on top of a UI-defined pipeline
- Cross-application dependencies and deployments: The ability to deploy Salesforce and Zendesk (and other apps) changes in a single deployment.
- Free tiers that solve real-world problems such as impact analysis, etc.
Many of these capabilities are already supported by Salto, who I'm happy to acknowledge is my employer; therefore, I have a strong bias. That said, similar arguments can be made for other DevOps vendors and their unique capabilities.
The multi-app approach is a very interesting value proposition. The ability to use a single platform for managing deployments and CI/CD across your entire business application stack is very powerful.
Salto has the advantage that it was built with that use case in mind. Other DevOps vendors may need to make significant changes to their architectures (or build entirely new products) to support other business applications.
In any case, this is only one example. Other DevOps vendors also have unique capabilities that others don't have, and that still makes them competitive against DevOps Center.
Verdict
So, are Salesforce DevOps vendors dead? Not at all, but we will see a dramatic increase in innovation and differentiation if they are to stay competitive with other vendors and Salesforce.