‘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.
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:
Whether you’re an experienced developer or someone who works in operations – we’ve got something valuable for everyone!
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.
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:
| Term | Definition | Can Exist Without | Cannot Exist Without |
| Release Management | The process of moving requirements for change through to a manifestation of change in a productionised software environment such that those requirements are met. | • DevOps • Automation Software • Source-control • CI/CD • Sandboxes | • A well-defined strategy |
| Source-based Development | Using an SVCS (source version control system) such as Git to track all changes made to a system’s meta-data and/or code base and to consider the SVCS master as the ‘source of truth’ and to deploy changes through a path-to-production from the SVCS. | • DevOps • Automation Software • CI/CD • Sandboxes* *Although not recommended without | • Release Management* *The term is ‘source-based development’, not ‘source based backups’, which can apply to other domains beyond release management |
| Pull Request (or Code Merge) | A pull request is an approval-based request to merge one SVCS branch of files or meta-data with another. When a developer has finished a piece of work in their own working copy (branch), they will use software (Git) to combine their local changes with the latest version of the software stored on an SVCS server. Peers will then receive a notification, and review those lines of difference between the target branch and the branch being merged, and if approved, the changes will be adopted in the target branch. | • DevOps • Automation Software • CI/CD • Sandboxes | • Release Management • Source-based Development |
| Pipeline | Pipelines are usually manifested as predefined ‘jobs’ in automation software that run scripts to execute unit tests and other tasks, check results, and then deploy code from a SVCS to a target server environment hosting software. | • Sandboxes* *Although not recommended without | • Release Management • Source-based Development • DevOps • Automation Software • CI/CD |
| Container / Virtual Container / Docker Container | A container in DevOps usually refers to a disk image of an operating system (such as Unix) with preinstalled software needed by a pipeline to execute specific automation tasks. Rather than have a pipeline install software in a virtual environment, and then have other scripts to configure that environment, it is sometimes easier and quicker to simply mount a disk image where everything is preconfigured to assist with managing deployment automation activities. For example, mounting an image of a Unix OS with SFDX and Git software preinstalled is often quicker than having scripts run to install Git and SFDX every time you want to execute a pipeline job. | • Sandboxes | • Release Management • DevOps • Source-based Development • Automation Software • CI/CD |
| DevOps | The process of automating as much of the Software Release Management process as possible through Processes, Tools, Ways of working, and a recognised Team Structure that brings together Developers and Operations | • Continuous Integration/ Deployment | • Release Management • Automation Software • Source-based Development • Sandboxes |
| Continuous Integration (CI) | A branch of DevOps concerned with automating all deployment processes up to (and including) User Acceptance Testing | • Release Management • Automation Software • Source-based Development • DevOps • Sandboxes | |
| Continuous Deployment (CD) | A branch of DevOps concerned with automating all deployment processes up to (and including) Production | • Release Management • Automation Software • Source-based Development • DevOps • Sandboxes |
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?
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.
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.
Mark Hartnady
Head of Architecture
VRP Consulting UK
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. To get in touch please email: mark.hartnady@vrpconsulting.com
What are the top 3 ways nonprofits can use Salesforce data to scale their fundraising efforts? Laura Croudace, VRP’s Nonprofit Practice Director, reveals the top 3 benefits of Salesforce for nonprofits.
Read more
Learn how to choose the best Salesforce delivery strategy to smoothly, swiftly and cost-effectively achieve your goals, in an article by VRP’s Coen Backer.
Read more
Workflow Rules & Process Builder are being deprecated by Salesforce in favor of flows. Here's what you need to know an do about their retirement.
Read more