The "No software" platform
The meteoric rise of Salesforce has provided us with a platform that lives up 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 grows with the needs of your business and organisation.
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 organisations, requires rigorous change management to ensure that changes are effectively communicated from the business to the implementation team, configured and built correctly, suitably verified and tested to ensure it matches what the business actually wanted, and finally 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?
DevOps for Salesforce is different
The remit of DevOps in Salesforce is a little different to in other platforms, and boils down to any part of the develop-release cycle that’s still manual, but can be automated. There are four main areas as targets for automation:
- Releases, via continuous integration and repeatable deployments
- Tracking org changes
- Unit testing
Salesforce itself removes a lot of the complexity of other DevOps processes. Managing infrastructure, scalability, hosting, 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 practises.
The lure of “best practice”
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, whilst 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.