A proposal for a Salesforce DevOps Manifesto
In a recent LinkedIn post, Pablo, an influential figure in the Salesforce community, proposed a manifesto or a set of guiding principles for Salesforce DevOps. We have lived and breathed these principles for years and are glad to see these ideas on the brink of becoming mainstream.
Let’s delve into these principles.
Automated Deployments Over Deployments Checklists
A no-brainer: we are human; we make mistakes, forget things, and get bored doing repetitive tasks. Manual deployments lead to environments discrepancies. Leading to cascading issues, and any Salesforce implementation relying on manual deployments ultimately grinds to a halt.
Organisations must invest in tools and processes to enable automated deployments, with version control systems at their core.
Source-Driven Deployments Over Org-Based Deployments
Implementing this principle requires a solid commitment to using version control systems like Git. All changes should be committed to a repository, reviewed through pull requests, and deployed through automated processes.
This approach facilitates collaboration among team members and ensures greater transparency, which is crucial for a few regulated industries.
Source-Driven deployment enables Just-In-Time environment provisioning.
A few metadata should not be in the version control system:
- Non-core capabilities: some reports, dashboards, or list views do not deserve to be version-controlled.
- Environment-specific configuration: especially security-related ones that should never be in a version control system.
- User orientated: for example, queue members assignment.
Just-in-Time Environments Over Long-Living Sandboxes
In traditional Salesforce development, teams rely very often on long-living sandboxes, which inevitably leads to environments out of sync with production.
Just-in-time environments are created dynamically and continuously up to date with the latest codebase. JIT provisioning must be fast and rely on Scratch org pools or Sandbox pools created by automated processes. Periodically executing these processes will refresh the pools and avoid their decay.
A modular structure is required to be able to create these environments. Salesforce teams must stop thinking in terms of individual metadata and start to think in terms of related metadata who participate in supporting a feature or a business capability.
Modular Applications Over Monoliths
Modular applications offer numerous advantages over monolithic architectures, including easier maintenance, better scalability, and more straightforward updates. In a modular system, changes to one part of the application will not impact others, reducing the risk of widespread system failures.
Understanding fundamental software engineering principles (loose coupling, abstraction, etc.) and proceeding iteratively by extraction and refactoring transforms a monolithic Salesforce implementation into a modular system. More on this topic here.
Once a Salesforce implementation is modular enough, the next stage is to reduce the complexity of the branching strategy.
Simple Branching Strategies Over Org-Based Branching
Salesforce branching strategies are usually complex and circumvoluted. A branch represents the state of an environment. Teams propagate changes from one branch to another and spend considerable time synchronising these branches. This approach mimics Changesets, but instead of moving a change from one org to another, they move from one branch to another.
Salesforce teams must decouple branches from environments to enable a simple branching strategy.
Continuous Integration creates artifacts (from the modules). A group of versioned artifacts defines a release deployed by the Continuous Deployment process. More on this topic here.
Conclusion
These principles are crucial for the future of Salesforce development. Customers perceive Salesforce as an expensive platform. They will leave the platform if they don’t get the expected outcome. The above principles are essential to deliver new capabilities at speed.
