Salesforce CI/CD | Author of "Clean Apex Code" | Product Manager and Software Engineer
New version of the Salesforce DevOps Manifesto! ?? Our collective experience of deploying Salesforce applications has led us to embrace the following principles: ?? Prefer development 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. ?? I came up with this new version after reflecting on the first one I came up with a few weeks ago, which was later refined by Ramzi Akremi in his article "A proposal for a Salesforce DevOps Manifesto" (a great read!). The idea is this one is more inclusive and focuses on the principles behind the principles :) and not the how-to. This way, these can be interpreted and not dictated. You can read more about my rationale here: https://lnkd.in/gkuQbxYJ What do you think?
I completely agree with this manifesto and have enjoyed watching it evolve from version 0.0.1. The current wording, particularly concerning the properties of development environments, strikes a great balance - it includes the most relevant aspects while remaining concise. Thank you for starting and advancing this Pablo Gonzalez, as it greatly benefits the Salesforce ecosystem ?? ???
Salesforce's DevOps center branching strategy conflicts with this point - "Think of sandboxes as test environments; avoid coupling them to Git branches". I agree with your point though. We have adopted the tool and it creates a mess for us to maintain changes in git specially for metadata stuff that gets modified for multiple tasks. It would be great if you could share some insights on how to handle branching in a Salesforce devops pipeline that handles merges properly and does not lead to change loss while deploying to other sandboxes for UAT or integrated testing
Seems like "production-like development environments" and "not org-based comparisons and deployments" are at odds. How do you quantify whether or not an org is "production-like" if you don't do org-based comparisons? Why would an environment need to be "production-like" if focusing on "artifacts, deployment candidates, and versions"? Shouldn't a modular design with extensive automated tests etc. render the 1st point irrelevant? Caveat: Playing a bit of devil's advocate here, because I personally think org-based development on Salesforce should be utilized for things which be built and deployed without code (as of today, based on available features). But I do see a gap/conflict as-written if we're to go the other way.
I love it! I might change "shared sandboxes" to "overcrowded environments" which would align with Well-Architected and applies more generically. Many ISVs use a TSO or persistent clones built from a TSO as test orgs that have the same overcrowding and state drift challenges. I'd also propose adding composable with modular. The distinction being that there's value in both having modular architecture and the ability to compose different combinations and configurations of it.
*cough* cumulus flow *cough*
I'd suggest keeping the "prefer" cadence from the Agile Manifesto (which was a stroke of genius). ?? Prefer development environments that are -ephemeral- temporary, integrated, and production-like over stale, shared, and out-of-sync sandboxes ?? Prefer modular architectures over monoliths and happy soups ?? Prefer automation over deployment checklists ?? Prefer sandboxes and scratch orgs to test each change to environments coupled over standing Git branches ?? Prefer artifacts, deployment candidates, and versions over org-based comparisons and deployments.
Hi Pablo, can you elaborate on why you try to avoid coupling org to Git branches "long-term"? For my projects, certain "high up" orgs (think full-sandbox, very closely aligned with Prod) have long life spans and, because of this, are linked to it's source branch for the same long life. I don't think we're yet mature enough as a practice to be able to spin up major, integrated, high volume user test orgs quickly enough to achieve this
Mostly Harmless
1 年Nice work! -- Have you considered setting up the manifesto as an Open Guide, like these * https://github.com/DreamOps/og-sfdx/blob/master/1GP.md * https://github.com/open-guides/og-aws I also have a Atlassian Confluence site under an open source agreement that I'd love to share with a project like this one, if you'd like a place to collaborate: * https://dreamops.atlassian.net/wiki/spaces Onward!