Salesforce DevOps Manifesto 0.0.3
A few weeks ago, I proposed a Salesforce DevOps Manifesto; a set of principles or guidelines to move the industry forward on how we should think about Salesforce DevOps.
This was my initial version:
We deliver Salesforce applications by valuing:
Just-in-time environments over long-living sandboxes.
Source-driven deployments over org-based deployments.
Simple branching strategies over org-based branching.
Modular applications over monoliths.
Automated deployments over deployment checklists.
Together, we embrace these principles to enhance agility, collaboration, and the efficiency of Salesforce DevOps practices
Version 0.0.2
Later, Ramzi Akremi expanded on the principles in his article titled "A proposal for a Salesforce DevOps Manifesto".
Ramzi Akremi
I won't try to summarise his points as it will do the article a disservice; please read it as it's not too long and expands on why these principles are important.
Core principles
This new version caused me to spend some time thinking about why I wrote what I wrote; what are the principles or foundations behind these other principles? For example, I realised when I wrote "simple branching strategies over org-based branching", I was really talking about de-coupling your sandboxes from your Git branches, something that even the Salesforce Well Architected Framework encourages.
Also, when I wrote "just-in-time environments over long-living sandboxes", I was thinking of the ability to work in production-like environments, one of DevOps's core tenants. Ideally, how we achieve production-like environments shouldn't be part of the manifest, as it dictates a solution rather than focusing on the principle.
With this in mind, I want to give a try at creating a new version of the manifest, one that is a bit more inclusive and generic, to allow for the principles to be interpreted and not dictated.
I also moved away from using the same tone as the Manifesto for Agile Software Development; as in that manifesto, they value both sides of the equation, they just value the left side more (i.e responding to change over following a plan); whereas in the case of the Salesforce DevOps Manifesto, we are saying you should try always to follow these principles; they aren't preferred over something else.
Version 0.0.3
Here it is
Our collective experience of deploying Salesforce applications has led us to embrace the following principles:
Prefer develppment environments that are ephemeral, integrated and production-like over stale, shared and out-of-sync sandboxes
Think of modular architectures instead of monoliths and happy soups
Automate everything that can be automated instead of using deployment checklists
Think of sandboxes as test environments, avoid coupling them to Git branches
Think of artifacts, deployment candidates, and versions, not org-based comparisons and deployments
Together, we embrace these principles to enhance agility, collaboration, and the efficiency of Salesforce DevOps practices
That's it. I think this captures the essence of what I was trying to say a bit more without going into the specifics of how to go about it.
What do you think?