Demystifying DevOps in Salesforce

‘DevOps’ is a term that’s often casually thrown around in the world of software development, but is often misunderstood when it comes to Salesforce. That’s why I’ve written this article: to bring some clarity to the topic of DevOps in Salesforce.

Concepts we’ll explore in this article

DevOps as a practice has been around for decades and there are many organizations who have successfully implemented its methodology. However, if you’re new to the concept or just want to understand how it can help your release management needs, then keep reading!

This article will explain everything about DevOps in Salesforce, and solidify your understanding of the following concepts:

• Release Management
• Source-control
• Source-based Development
• Pull Requests and Code Merges
• Automated Testing and Deployments
• Continuous Integration
• Continuous Deployment

Whether you’re an experienced developer or someone who works in operations – we’ve got something valuable for everyone!

What is DevOps and why do we need it?

Before we get into any Salesforce nuances, let’s start with the problems DevOps aims to help us with in the world of traditional software development.

DevOps is the process of automating as much of the software release process as possible through Processes, Tools, Ways of working and a recognised Team Structure that brings together developers and operations.

The term itself is a portmanteau of ‘Development’ and ‘Operations’ and comes from the world of traditional software management.  It was coined by software engineer and guru Patrick Debois in 2009. Debois was trying to introduce this new concept as a way to overcome many of the problems associated with ‘Development’ teams being responsible for developing software and ‘Operations’ teams being responsible for deploying and maintaining it. In this situation, different Processes, Tools, and Ways of Working, and critically, priorities, often lead to excessive management overhead, time lost in development lifecycles and a slower time-to-market.

DevOps (and now even DevSecOps) was thought of as a way to bring these teams together, and to speed up the time-to-market, by offering a common toolset, automation as a principle and aligned processes for working with software.

DevOps terminology

The terms ‘DevOps’, ‘Release Management’, ‘Continuous Integration or Deployment’ and even sometimes ‘Source-based Development’ are very often interchanged and erroneously used to mean the same thing. In reality, they are all very different concepts and the terms are not interchangeable. 

DevOps may be part of a Release Management Strategy (although it doesn’t have to be) whereas Release Management is always the overarching domain of DevOps. DevOps almost always includes Source-based Development and Automation Software.

When we refer to ‘DevOps’ in a Salesforce context, we are almost always talking about the process automation behind development, testing, and deployments, which are all within the domain of ‘Release Management’.

This hierarchy/taxonomy of definitions is important. Being casual about these terms can lead to confusion and/or mismanaged projects.

It is quite feasible to have a Release Management process that is completely manual (even if using the latest cutting-edge tools) without any automation at all. Should we then be referring to this way of working as DevOps? Probably not.

Here is a matrix of terms to help you gain a better understanding:

DevOps in Salesforce contexts

When applied to Salesforce, or other ‘multitenant’ platforms, some DevOps concepts do not apply (or apply to a lesser extent). 

This is particularly the case with those related to Infrastructure, which in traditional software organisations is the responsibility of ‘Operations’ teams. To learn more about how DevOps applies to Salesforce, using Copado (a single solution option) as an example, why not try this Trailhead?

So, which methodology is right for your organisation?

Every business is different. Every organisation has its own unique set of needs and constraints, and therefore there is no ‘one size fits all’ methodology that can be uniformly applied to managing Salesforce releases. 

ISVs, Non-Profits, Small Businesses, SMEs, Enterprise Customers (with and without Experience Sites for Customers or Partners), big budgets, small budgets, existing IT departments with strict policies, or outsourced IT departments with flexible policies… VRP has experience working with organisations of all sizes and needs.

We would be delighted to hear from you, and help you make the most appropriate decision that considers your existing policies, budget, and existing processes, in order to help design a Release Management Strategy that’s right for you.

Here to help you succeed with DevOps in Salesforce

VRP Consulting has many years of experience helping Salesforce Customers and Partners (ISVs) improve their Release Management processes. We support small customers still using Change Sets, big customers with sophisticated DevOps automation, and everything in between! The landscape of possibilities can be quite daunting, but we can help you understand the options available. So, get in touch to discuss the right approach for your business.

Get in Touch

About the Author

Mark Hartnady

Head of Architecture, VRP Consulting UKI

Mark Hartnady is one of our global architecture leaders, based in our London office. Mark has been working with CRM solutions, with a particular focus on the Salesforce platform since 2012 and has been instrumental in transforming enterprises with scalable, extensible solutions in the manufacturing, automotive, hi-tech and media sectors.