The meteoric rise of Salesforce has provided us with a platform that lives up to the No Software promise. We no longer need to deal with legacy on-premise software with large up-front costs, and instead have a platform that can be easily migrated to and that grows with the needs of your business and organization. 

There was a mistaken belief that No Software meant there would be no need for a solid software development lifecycle. But Salesforce — like all software that powers our organizations — requires rigorous change management to ensure that changes are effectively communicated from the business to the implementation team, are configured and built correctly, are suitably verified and tested to ensure it matches what the business actually wanted, and are delivered to production in a way that delivers the benefits to the end users. 

This process of managing change falls under the remit of Salesforce release management. So what is DevOps?

The remit of DevOps in Salesforce is a little different to that in other platforms, comprising any part of the develop-release cycle that’s still manual, but can be automated. There are four main target areas for automation:

Salesforce itself removes much of the complexity of other DevOps processes. Managing infrastructure, scalability, hosting, and even tests — traditionally the responsibility of ops, and, more recently, DevOps — is all handled by the platform itself.

Things are changing in the Salesforce world — in part through the introduction of Salesforce DX — but Salesforce teams are generally behind the industry curve when it comes to adopting more robust DevOps practices.

When we speak with Salesforce teams, especially those struggling with increasing complexity, there is often a desire to adopt a “best practice” approach to DevOps and their Software Development Lifecycle.

The most important thing to understand when defining how your team works and what their software development lifecycle looks like is what issues you’re struggling with and how the process you’re adopting is going to address those issues. We believe there is a spectrum of best practice, and you should implement the parts that are going to deliver the best immediate return on investment, while still laying a foundation to build upon.

There is no single correct answer that fits all. Hopefully, these guides will provide you with the information you need to understand what DevOps could look like for your company.
​
​
​