July 8, 2020
What is Salesforce DevOps? The What, Why and How of Salesforce DevOps

What is Salesforce DevOps? The What, Why and How of Salesforce DevOps

If this is your first-time hearing Salesforce DevOps, we’re not surprised. Many people have not heard the term before, but it might be interesting to hear that your company most likely already has DevOps. There are a lot of misconceptions about what DevOps is; some say DevOps is a position, others say it’s a process, but both of these would be incorrect. So what is Salesforce DevOps? To clear this up, let’s dive into what it really is.

It makes sense to first discuss DevOps as a label before jumping into the definition. As a label, DevOps refers to the type of people who manage a company’s software, specifically overseeing the running, performance, security, and change management of a system. The label DevOps is actually the combination of two individual labels, developers and operators, or in more Salesforce friendly terms, developers and admins.

Collaboration between developers and operators is of vital importance to maintain operations, as both teams work at either end of a system management spectrum. Simply put, developers are responsible for managing change to a company’s system, whereas operators maintain stability by ensuring the system performs as expected for users. The table below breaks down the overall duties of the two teams.

Overall Duties of the Developer and Operator Teams
Overall Duties of the Developer and Operator Teams

Now that we have a good grasp on what DevOps is as a label, let’s jump into the definition.

What is Salesforce DevOps?

Salesforce DevOps is an engineering practice that aims to unify the two different teams, developers, and operators. As we have already discussed, these teams manage entirely different sides of a company’s system, so it should come as no surprise that the practice of team unification is vitally important to the health of an organization. When done correctly, good Salesforce DevOps practices yield more dependable releases, faster-to-market times, increased deployment frequency, and strong business objective alignment. When poorly practiced, DevOps wields the power to bring an organization to its knees in chaos, down-time, and loss of data.

To help you keep order in your organization, we’ll discuss two different tools that help maintain good Salesforce DevOps practices: version control and release management. Salesforce has some sweet tools to help with this, and we’ll throw in a couple tips and tricks along the way. So let’s jump in with version control.

#1 Version Control

If we want to discuss version control, we first need to quickly review application lifecycle management (ALM). An application lifecycle refers to the process that an application undergoes from development to release. While at first glance this sounds like a linear process, an application lifecycle is instead a circular one, beginning before development and circling back after deployment. The stages of ALM can be seen in the figure below.

Stages of Application Lifecycle Management (ALM)

The stages with the most interaction between developer and operator teams are the deployment and requirements stages. It’s in these stages where we also see a majority of Salesforce’s native DevOps tools, and the location of the first tool of discussion, version control.

Version control as it pertains to development is the process of keeping track of changes to an application as it undergoes multiple rounds of the application lifecycle. To help understand this, let’s take a look at an example of version control that Salesforce natively offers.

If you have ever worked with Process Builder or Flow Builder, then congratulations, you have already been implementing version control in your organization without even knowing it! Let’s say you have a problem and you start by discussing the requirements of the solution. You decide on building a process using Process Builder, create the process, and test it with a couple of records. All of the tests went well so you deploy it into production and monitor the feedback from your users. You have just completed the first lifecycle of your new application.

It’s Monday morning and Jami from sales calls. She thanks you for your new process that’s working wonderfully and wants to see if you can expand the process to do some other things as well. This means that there are some new requirements, so it’s here that you start the second lifecycle of your application. You discuss the new requirements, make the developments, perform some testing, and roll it into production. Uh oh, something is wrong this time though. With the new changes, the process is not doing what you originally set out to do when you first created it.

It’s at this moment we can see why version control is crucial to DevOps teams, and why Salesforce built version control directly into Process Builder and Flow Builder. Every time you change a process or a flow, you are actually creating a new version of that process or flow. With changes saved as new versions, it becomes very easy to quickly re-activate a previous version of your application and review the issues of your current version.

It’s important to note that this native version control is only offered on native salesforce automation tools. This means that if you are developing with apex, Salesforce does not offer native version control. If you are looking to implement version control into your apex programming teams, and we highly suggest that you do, you will need to develop on the Salesforce DX platform. We have a great article introducing Salesforce DX that can be found here.

#2 Release Management

Knocking right on the door of version control is Salesforce release management. Both have heavy roots in the deployment stage of ALM, but where version control is really on the developer side, release management is primarily on the operator side.

Release management controls how new versions of applications get released into production. Improper release methods can lead to partial deployments, where only a portion of what was developed gets deployed. This can wreak havoc on any system. Operators need to be able to control the order and timing in which different applications and application versions are released into production, and Salesforce comes standard with native tools to help with just that.

There are two main types of release management tools; changesets and managed packages. Choosing which one of these release management tools to use depends entirely on the nature and destination of the application. Changesets are useful when the development team has created an application that needs to be transferred between a sandbox organization and a related organization, such as your company’s production org. Through changesets, metadata can be transferred from one organization to another without the need for bulky, complicated processes.

To transfer new applications through changesets, the application must first be packaged into a changeset on the source organization by the developer team. Once compiled, the changeset then gets pushed to the target organization and sits in a queue awaiting deployment. On the production side, an operator team member reviews the changeset and conducts any necessary testing needed to confirm readiness for deployment. If tests fail, then the failures can be communicated to the development team, modifications can be made, and the changes can be re-pushed to the changeset. Once all tests pass, the operations team member can deploy the changeset into production and begin monitoring for user feedback. While changesets can be useful, they involve extremely manual and time-consuming processes that lead to many changeset users seeking out an application lifecycle management system such as Flosum.

If the application is built more for sale or organizations that are not related to the development organization, then changesets can’t be used and managed packages become the primary release management tool. Managed packages work the same way that changesets do, where they get packaged by the development team, but the transfer method is different. Managed packages are stored in a location and accessed via a URL. From that URL, the application can be downloaded into an organization. Any changes to the application are made via updates that get installed just like any other program.

_____

It’s important to remember that DevOps is not a process or a person, it’s a practice. The two tools that we discussed here play into good overarching DevOps practice, but there are many more components that go into proper application management. If you are looking for more information, Salesforce has a great introduction that expands on the topics discussed in this article which can be found here.

Next Steps