Your team grows from 4 to 20+. Pull requests stack up, admins ship new Flows, devs commit Apex and LWC, the business wants “that feature by Friday.” If you don’t agree how you work right now, a monorepo becomes a landfill of random artifacts. The way out is simple, not heavy: modularity (unlocked packages), disciplined delivery (branching, PRs, quality gates), and transparent architectural decisions (ADR). Add a little DevOps Center and a sane environment strategy, and releases become boring—in a good way.
Salesforce’s own Well Architected guidance pushes teams off org based development toward source driven releases and the most stable release mechanisms, explicitly putting Unlocked Packages first, then DevOps Center, then CLI source deploys. That’s your North Star.
A monorepo is one repository with multiple distinct projects and well defined relationships. If those relationships aren’t explicit, it’s just a big repo with shared chaos. The clearest industry definition lives on monorepo.tools (and it ships handy visuals you can embed).
On Salesforce, the cleanest way to get real modularity is Unlocked Packages. They force you to define boundaries and dependencies, version your changes, and roll forward/back predictably—exactly why Well Architected calls them “the most stable release artifact.” Packaging also surfaces metadata dependency issues early, instead of on Friday night during a hotfix.
Concretely:
Split your repo into domain oriented packages: catalog, checkout, customer, integrations/payments, shared/platform, etc.
Reflect those boundaries in sfdx-project.json using multiple packageDirectories—that’s the official pattern for multi package projects.
Module health checks: no “hidden” cross imports, CODEOWNERS per package, semantic versioning, and low cross package churn.
2) Branching & releases: simpler is faster
Big e commerce teams love to debate GitFlow vs trunk based. Use a lightweight, almost trunk setup unless you truly run “release trains”:
If you need to explain GitFlow vs GitHub Flow to your stakeholders, Vincent Driessen’s post (with the now classic diagrams) is perfect. Even he later noted: for continuous delivery, pick a simpler flow. Embed his big diagram and the –no-ff visual to show why you don’t squash everything.
Salesforce wise, releases feel best when you ship package versions (fast install, easy rollback) instead of “bags of metadata.” That’s precisely the resilience guidance from Salesforce Architects.
3) Code review that prevents sprawl
A good PR is small, self explained, and machine checked. Humans discuss design; robots nag about style.
Use Salesforce Code Analyzer (v5) in CI. It unifies PMD (Apex), ESLint (JS), RetireJS, and more under one CLI and integrates with VS Code and pipelines. Install the new @salesforce/plugin-code-analyzer and run it in your Action/Job before merge.
Minimal CI snippet:
And remember the hard gate for prod: Apex tests must cover at least 75% of your Apex, and tests must pass. Don’t skate on this—the platform enforces it.
CODEOWNERS example
PR template seed
4) ADRs: decisions that won’t get lost in Slack
Architecture Decision Records (ADR) are short notes capturing one important decision (context → options → decision → consequences → status). Keep them in the repo, review via PRs, and link them from PR descriptions so choices don’t vanish in chat history. Great primers and templates live at adr.github.io (including the streamlined MADR template).
If you want visibility over time, use adr tools to generate a DOT graph of relationships (“supersedes,” “amends”). Micha Kops’ article shows the commands and example graphs—drop the PNG into your repo wiki or architecture README.
5) DevOps Center: one flow for low code + pro code
Mixed teams (admins + devs) often struggle to align around Git. DevOps Center provides a clear UI on top of GitHub: Work Items → branches → PRs → promotion through environments. It talks to GitHub over the GitHub REST API and OAuth, so everything stays traceable.
If you need the data model (Work Item, Repository, Environment, Pipeline Stage, etc.), Salesforce publishes a Developer Guide with object references—handy when you automate reports or guardrails.
This isn’t a replacement for packaging or CLI; it’s the front porch for source driven delivery—fully aligned with the stable release guidance above.
6) Environments: decouple “where you work” from “what you ship”
Scratch orgs, sandboxes, full copies—those are places to work, not release artifacts. In a source driven model, Git is the source of truth; environments are ephemeral. That’s straight from Well Architected’s environment strategy: stop using org based development, and organize releases around source/branches and stable artifacts (packages or DevOps Center promotions).
7) Monorepo anti patterns (and fixes)
Everything in one force-app: split into domain packages, declare dependencies in sfdx-project.json.
Giant PRs: smaller, more frequent PRs; CODEOWNERS + branch protections.
Style/security left to reviewers: fail the build on Code Analyzer violations.
Tests after coding: enforce coverage and scenario breadth; the 75% rule isn’t optional.
“Temporary” changes directly in prod: promote via DevOps Center and Git so history/audit remain intact.
Quality gates: add @salesforce/plugin-code-analyzer to CI and break the build on violations.
ADR discipline: /docs/adr, short template, PRs must link decisions.
Releases: ship package versions on a release cadence; use DevOps Center where it helps collaboration.
Conclusion
A monorepo isn’t a junkyard if the code follows package boundaries, every change passes machine enforced gates, and decisions live as ADRs next to the code. DevOps Center closes the gap between clicks and Git, while stable release artifacts (ideally Unlocked Packages) make rollouts predictable. That’s not bureaucracy—that’s speed without fear on Salesforce.
Oleksandr Shvaikin is an award-winning Salesforce developer with 13+ years in IT. A Gold Winner at the ECDMA Global Awards, he has judged major hackathons like X-Hackathon and Vanilla Web Hackathon. Author of Udemy courses and scientific publications, Oleksandr has delivered high-impact solutions for companies including ABInBev, Gameloft, and SoftServe, saving clients tens of millions annually.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
