[Paper] 可运行目录：Monorepo vs. Multi-repo 辩论的解决方案

Source: arXiv - 2512.03815v1

概述

本文介绍了 Causify Dev，一种混合代码库组织模型，用全新的原语——可运行目录（runnable directory）取代传统的单体仓库（monorepo）与多仓库（multi‑repo）之争。通过将每个目录视为自包含、可独立执行的单元，作者声称可以在保持单体仓库一致性的同时，享受独立仓库的隔离性和模块化优势——且无需常见的工具链烦恼。

关键贡献

• 可运行目录概念 – 定义了一种将源码、构建脚本、测试和部署描述文件打包为单一可执行单元的目录。
• 轻量统一环境 – 一个轻量级共享运行时（例如最小化的 Docker 镜像），所有可运行目录继承它，从而保证整个代码库的工具版本一致。
• 容器优先 CI/CD 工作流 – 使用基于 Docker 的流水线，为每个可运行目录自动启动隔离环境，简化依赖管理并实现并行执行。
• 混合仓库布局 – 展示了如何在单个 Git 仓库中容纳众多可运行目录，保留单体仓库的优势（单一真相来源、原子提交），同时规避其可扩展性瓶颈。
• 实证评估 – 在真实的微服务套件上进行基准测试，显示相较传统单体仓库，CI 构建速度提升最高可达 40 %，依赖相关故障下降 30 %。

方法论

1. 可运行目录的设计 – 作者制定了规范，要求每个目录必须包含：
   • causify.yaml（元数据、依赖、入口点）
   • Dockerfile（或指向共享轻量镜像的引用）
   • 标准子文件夹（src/、test/、deploy/）
2. Causify Dev 的实现 – 一个 CLI 工具解析元数据，生成每个目录的 Docker 镜像，并将其注册到驱动 CI 流水线的中心编排器。
3. 实验设置 – 将一个已有的 12 服务、250 k 行代码的单体仓库（Java、Node.js、Python）迁移至可运行目录模型。CI 流水线在 GitHub Actions 与 Jenkins 上分别运行原始单体仓库和 Causify Dev 版本。
4. 收集的指标 – 构建时间、测试不稳定率、依赖冲突事件数以及开发者入职时间（通过简短调查测得）。

结果与发现

数据表明，隔离每个服务的环境可以消除大多数导致大型单体仓库“依赖地狱”的问题，而共享的轻量镜像则防止了版本漂移。开发者也反馈说，由于被测试单元边界明确，修改代码时更有信心。

实际意义

• 更快的 CI/CD – 团队可以在目录层面并行构建，而无需担心交叉污染，缩短反馈周期。
• 工具链简化 – 无需使用复杂的工作区管理工具（如 Bazel、Lerna）来强制隔离；Docker 完成了大部分工作。
• 更易扩展 – 添加新微服务只需在仓库中新增一个可运行目录，无需创建全新仓库并管理访问控制。
• 环境一致性 – 轻量共享镜像保证每位开发者、CI 运行器以及生产部署使用完全相同的基础工具（编译器版本、代码检查器等）。
• 渐进式迁移路径 – 现有单体仓库可以逐步重构：一次将一个模块转为可运行目录，降低迁移风险。

局限性与未来工作

• Docker 开销 – 虽然容器提供隔离，但额外的层会增加本地开发启动时间，尤其是对非常小的工具；作者建议未来可探索轻量替代方案（如 podman 或 nerdctl）。
• 跨目录耦合 – 该模型假设耦合相对松散；紧密耦合的组件仍可能需要共享库，从而重新引入部分单体仓库式的协作需求。
• 工具成熟度 – Causify Dev 仍是原型；要实现更广泛的采用，需要更丰富的 IDE 集成、对非 Docker 运行时（如 Windows 原生构建）的更好支持以及更完整的文档。
• 实证推广性 – 本次评估仅针对单一大型代码库；后续研究应在不同语言、领域（如数据科学流水线）以及不同规模的组织中进行验证。

结论：可运行目录提供了一种务实的折中方案，使开发者能够在保持单一真相来源的同时，享受隔离构建带来的安全性和速度。如果你的团队正为单体仓库的可扩展性或多仓库的管理开销而苦恼，Causify Dev 值得一试。

作者

• Shayan Ghasemnezhad
• Samarth KaPatel
• Sofia Nikiforova
• Giacinto Paolo Saggese
• Paul Smith
• Heanh Sok

论文信息

• arXiv ID: 2512.03815v1
• Categories: cs.SE
• Published: December 3, 2025
• PDF: Download PDF