Salesforce DevOps: What took so long?

Salesforce DevOps has been a long time coming. However, DevOps has long been a popular methodology for IT teams. So what has caused the slow adoption of DevOps by the Salesforce community? First, Salesforce isn’t a code-first environment. Second, the production org has always been the source of truth. And third, creating reproducible environments has been extremely challenging.In this blog, we take a closer look at these factors. Then we explain how Prodly directly addresses each one to facilitate Salesforce DevOps.

3 reasons Salesforce was slow to adopt DevOps

We can attribute the Salesforce ecosystem’s slow adoption of DevOps to the following key principles.

1. Salesforce is not a code-first environment

Salesforce is first and foremost a low-code platform. It’s as much declaratively configured as it's programmatically configured. That’s why it’s such a great tool for low-code developers such as Salesforce admins and citizen developers. Often, Salesforce admins, business analysts, and project managers have great ideas. Unfortunately, they’re still excluded from conversations due to their inability to work with code-heavy DevOps tools. To achieve successful adoption of DevOps for any team, low-code and no-code citizen developers must be first-class citizens from the very beginning. This is why Prodly DevOps is designed with the lowest technical user in mind.

2. The production org has historically been the source of truth

Within Salesforce, we think of production as the source of truth. The problem is that production is always evolving—and there’s no real history of changes. In DevOps, the code is the source of truth. The code is versioned, and every change is stored in a repository so it’s easy to roll back changes if there’s an error. Think of the “track changes” feature in a document. For Salesforce DevOps to be successful, we need to version not just the code, but also the declarative configurations. This is why Prodly helps you version your Salesforce data with GitHub, Azure, and Bitbucket integrations.

3. Creating reproducible environments has been challenging 

One important DevOps principle is to be able to easily create reproducible environments. Why? Because by giving each developer their own org, they have a safe place to play around and test new ideas without stepping on each other’s toes. So it’s imperative to be able to quickly spin up and discard new orgs. Salesforce has sandboxes. However, they’re not truly reproductions of production because they don’t contain all your data. Even Full Copies get out of sync with production quickly—plus, they can only be refreshed every 30 days. Salesforce data is highly relational, and those data relationships are hard to maintain org to org. That’s why most companies fall into one of two buckets:

• Everyone shares the Full or Partial Copy sandbox. All the work happens here, and people overwrite each other’s work by mistake. This frequently results in access restriction to certain data. 
• They work in Developer Pro sandboxes without the right test data, meaning they can’t efficiently build new stuff or test it very well.

To be successful with Salesforce DevOps, you need to be able to create true copies of production. What’s more: You need to be able to do this really quickly. That’s why Prodly Sandbox Management allows you to select, filter, and seed data into any org in minutes. Check out our ebook Maximize your Salesforce orgs with sandbox management to learn more.