skip to Main Content
Silver Imac Displaying Line Graph Placed On Desk

Salesforce Devops in Early 2021

Lately, “Salesforce Devops” is a hot topic of interest in the higher echelons of Salesforce management. Why? Because Salesforce development is still frustratingly slow and not getting faster, fast enough. 

To address the problem some software vendors and consultants are telling enterprise customers you just need to adopt the ways of the devops to fix the problem! 

Let’s take a look at this new trend to see if “devops” is a viable way to fix some deep-seated Salesforce developer productivity issues. We will start by looking at how we got here, try to define Salesforce Devops, take a quick look at the vendors, and then give solution architects and technology delivery managers a tool for making devops choices in 2021.

Salesforce Change Management Is Hard

The change management model used by Salesforce settled in by 2010, and the process of expansion continued. Back in 2010, Salesforce was not designed to use a “source of truth” about how an org is defined. The change management process was governed to ensure maximum uptime for end users, not maximum convenience for developers.

time for change sign with led light
Photo by Alexas Fotos on Pexels.com

To practice devops, in my humble opinion, one needs needs the capability to browse and run all of a project’s source code in a test environment. This is a problem, even with scratch orgs, because expressing a Salesforce org’s metadata and user-defined actions as source code is not 100% supported by Salesforce. 

The fact users can easily customize their orgs is a major source of Salesforce’s success. But, only in the last five years has Salesforce worked hard on making more source-code-based definitions of Salesforce configurations. And, without a reliable source code management technique in widespread use, implementing devops practices to speed up Salesforce development is difficult without employing elaborate tools and techniques.

Salesforce is definitely getting it’s act together concerning change management. By the end of 2021 we expect Salesforce to ship the final version of DevOps Center. With no-additional-charge and paid versions, DevOps Center should allow orgs associated with a Developer Hub to organize and share metadata.

Why Do Devops?

Using devops has accelerated software development in technology startups, major software companies and thousands of enterprise companies over the last ten years. Because the Salesforce community needs to get better at software delivery, it is important to learn from devops in order for Salesforce developers to service their users faster.

woman coding on computer
Photo by ThisIsEngineering on Pexels.com

But, what is “devops?” Here’s my definition. It is a crafting of developer systems, scripts, monitoring systems, ETL actions, container management, external systems, operational platforms and source code repositories to form a software delivery pipeline. I know, it’s a lot!

A functional description of a devops engineer’s role in an enterprise team is to create a Continuous Integration and Continuous Delivery (CI/CD) pipeline to automatically validate any changes to a source code repository, and ultimately deploy tested code to production.

Commit and Deploy!

For me, I finally entered the devops world when I could network dozens of Github repositories and automatically run system integration processes that resulted in a running system starting from scratch. Most importantly, I could perform iterative changes to my code in a localized developer environment, which allowed me to test and add new features to an end-user application faster.

I hit the moment of devops glory when I made a new commit to Github which automatically triggered a CI/CD process that updated all the Docker containers and deployed them to my test and production clusters.

cheerful asian man raising arms in excitement on sunny street
Photo by Allan Mas on Pexels.com

Devops also encompasses using cloud-based resources to host and deliver the services generated by the code. That means a devops engineer must automate the use of VMware, AWS, GCP or Azure through code and configuration files.

In 2021, devops is an attainable skill for a mid-level IT professional. Setting up a workflow for taking code changes that automatically perform unit tests, system integration, end-to-end tests, ETL migrations, and production deployment is now a repeatable software engineering process.

Now, setting up a delivery lifecycle for MySQL, PostgreSQL, Go, Typescript/Node, React, Angular, or Gatsby code running on many different delivery platforms can now be done with several free open source software (FOSS) solutions surrounded by helpful communities.

Clicks Over Code Makes Devops Hard

In the Salesforce world, what I just described is not an attainable skill by a mid-level IT professional. Managing changes to Salesforce production systems and creating a speedy developer pipeline is a highly advanced skill not yet in the possession of most Salesforce enterprise architects.

Currently, enterprise Salesforce developers need deep knowledge about the org in which they are working. Consultants must employ org discovery tools before making changes to the source code of a new org. This is a lot of overhead when compared to a “normal” devops process, where a new developer learns about a repository by cloning it, changing it locally, and then posting code changes for review with a commit action.

So, the fact that a Salesforce org’s state of metadata and active code may be constantly changing in an unreviewable way is quite a challenge for anyone testing and deploying new code to a large, complicated org.

Salesforce Devops To The Rescue!

When Salesforce displays weakness in an important area, you know what happens next. A crop of new and existing ISVs start competing with new products and services. This is happening again as Salesforce Devops grows into an emerging ISV category.

A convergence is now underway between existing Salesforce products and services and the FOSS devops engineering world to meet the heightened demand for Salesforce SDLC tools.

Salesforce Devops is the convergence of FOSS devops engineering with all the services designed to help enterprises run their Salesforce developer pipelines faster and safer

Vern’s Salesforce Devops List

I made a list of the companies that I identify as a Salesforce Devops company. Please check it out and submit any omissions, comments or corrections at [email protected].

https://docs.google.com/spreadsheets/d/1QZkwzbsEfRiu1-FYMemgDEbBWCmQ0gMBEZOwZd-SX20/edit?usp=sharing

I currently have 10 names on my Salesforce Devops ISV list. I omitted any generic CI/CD tools, devops platforms or companies that don’t have a Salesforce-first orientation from this select list. The Google Doc has a separate list of generic and other commercial devops tools used for Salesforce automation.

Salesforce Devops ISVs

NameURLVendor
AutoRABIThttps://www.autorabit.com/AutoRABIT
ClickDeployhttps://clickdeploy.io/Clickdeploy/Copado
Codescanhttps://www.codescan.io/CodeScan Enterprises
Copadohttps://www.copado.com/Copado
DevOps Centerhttps://quip.com/9acRAAfljeypSalesforce
[email protected] Solutionhttps://dxatscale.gitbook.io/sfpowerscripts/Accenture
Flosumhttps://flosum.com/Flosum
Gearsethttps://gearset.com/Gearset Limited
Metazoahttps://www.metazoa.com/Metazo
Prodlyhttps://prodly.co/Prodly

The goal of my list is to convey an unopinionated analysis of the features and capabilities of all the ISVs that fit my definition of a Salesforce Devops ISV. I welcome any offers of criticism, clarification or assistance to make the list better and more complete.

Use this link to add your own Salesforce Devops solution for consideration:

https://forms.gle/PUxgv7nu5vhjzLad9

Salesforce Devops Features

Solution architects and delivery managers need a feature matrix to help pick from these ISV options. And, a feature matrix helps decision makers perform a factor analysis of the competitors, aiding them to pick the right tool to solve the problem at hand.

Here are the factors I’ve picked so far. Let me know if I left something out.

  • AML Tools — Does the system use application management lifecycle tools, such as Agile or Scrum?
  • API/CLI — Does the system offer programmatic control using an API or CLI?
  • Backup — Does the system perform automated backups of Salesforce data?
  • CI/CD Tool — Can the system use a third-party continuous integration and continuous deployment tool?
  • Data Migration — Does the system migrate data between orgs, retaining record relations?
  • E2E Tests — Does the system facilitate end-to-end testing of an integrated system?
  • ETL Tools — Does the system incorporate data extract, translation and loading tools?
  • Linters — Does the system incorporate Apex PMD or other static code validation tools?
  • MDAPI — Does the system backup, restore and deploy Metadata API files?
  • Package — Does the solution employ a managed package from the ISV?
  • Profile Management — Does the system manage Profiles and Permission Sets?
  • Sandbox Management — Does the system manage, not just use, Salesforce sandboxes?
  • Security — Does the solution include security management tools?
  • Terms — The pricing model.
  • Type — The operational system architecture used by the vendor: SaaS for off-platform-based services, and Salesforce for org-based solutions.
  • UI Testing — Does the system offer testing of Salesforce UI?
  • Unit Tests — Does the system manage the execution of Apex Unit Tests?
  • VCS — Which Version Control System are used with this system?

But, What About Open Source?

The ISVs all have a different approach to Salesforce Devops, so what if you don’t want to use them or you have your own special requirements?

That’s where using FOSS and commercial solutions CI/CD like TeamCity, CircleCI or Travis CI play a role. Using these tools, you can build your own solutions using bash scripting, git, make, Docker and sfdx-cli.

text
Photo by Markus Spiske on Pexels.com

FOSS tools deliver fairly complete solutions in many deployment scenarios that use scratch orgs and org-based development techniques. Examples of using open source CI/CD tools with Salesforce DX world are found in Salesforce documentation and Trailhead training modules.

However, I must concede that the growth and popularity of the commercial Salesforce Devops ISVs points to the need of a high level expertise required to kickstart a broken Salesforce SDLC with modern devops practices.

Conclusion — Much Demand and Many Options

There is obviously a lot going on in Salesforce Devops, and it is for a good reason. The demand for business application development on the Salesforce platform has accelerated over the last five years, yielding a vast amount of backlogged work and new implementations.

Thankfully, the free open-source software world has now infected the mentality of Salesforce and the general Salesforce ISV community. Now devops is sufficiently trendy for the ISVs to claim the word “devops” for their own.

While we have not achieved “real devops” in the Salesforce world due to source code limitations, I do think the vendors I’ve highlighted deservingly bear the label of being Salesforce Devops ISVs. These ISVs are key to the growth of Salesforce because they are addressing painful Salesforce software delivery problems.

Salesforce Devops ISVs are worth a serious look, and likely a serious investment, if you are an enterprise solution architect or delivery manager who needs to speed up your developer pipelines. 

I hope the feature matrix I’ve shared here can help you make the right choice! Let me know what you think. — [email protected]

https://docs.google.com/spreadsheets/d/1QZkwzbsEfRiu1-FYMemgDEbBWCmQ0gMBEZOwZd-SX20/edit?usp=sharing

Want to add your product to this list? Submit it here:

https://forms.gle/PUxgv7nu5vhjzLad9

About Vernon Keenan