先给出一个经验法则:代码仓库蓝图用于安装项目依赖,组织蓝图用于安装多个代码仓库共享的内容,而企业蓝图用于安装每个组织都必须具备的内容。 各层级采用叠加方式,并按自上而下的顺序运行:企业 → 组织 → 克隆代码仓库 → 代码仓库。
第 1 阶段:一个代码仓库
acme-web,这是一个使用 Postgres 和 Redis 的 Rails 应用程序。两个工程师,共用一个代码仓库。此时还没有任何需要共享的内容,所以所有内容都放在代码仓库蓝图中。
他们在 设置 > 环境 > 蓝图 > 添加 中添加这个代码仓库,打开其编辑器,并编写:
acme-web (repository blueprint)
两年后,ACME 有五个代码仓库:
这是一个很有代表性的场景,因为这些代码仓库并不是彼此独立的:如果没有安装
acme-devtools,且 acme-sso 没有运行,那么在 acme-portal 里就无法开展任何有意义的工作。这就引出了两个问题。
“每个应用程序一个蓝图,还是只为开发 CLI 配一个蓝图?”
- 将全部五个代码仓库添加到环境中,这样它们都会被克隆到快照中。
- 将跨代码仓库共享的 setup统一放在组织蓝图中:语言运行时环境、Docker、本地主机名,以及内部 registry 的凭据。
- 为每个代码仓库分别提供自己的代码仓库蓝图,用于管理各自的依赖,以及各自的
knowledge条目 (lint、test 和 startup 命令) 。
acme-devtools 蓝图:代码仓库蓝图会在所有代码仓库都克隆完成后运行,但其中的步骤会在对应代码仓库的目录中执行,而且其中的 knowledge 条目只有在 Devin 处理该代码仓库时才会加载。如果由 acme-devtools 安装所有内容,那么在 acme-portal 中工作的会话将看不到任何 portal 的 lint 和 test 命令;而且只要 acme-devtools 的某个步骤失败,其他四个代码仓库表面上看起来正常,实际上却无法使用。
组织蓝图
Organization-wide setup
-
initialize与maintenance。 Docker、运行时和主机名属于一次性的系统设置,因此应放在initialize中。注册表凭据应在每次定期构建时刷新,因此应放在maintenance中。 这里特意没有包含acmeCLI 本身。它位于acme-devtools中,而组织级步骤会在任何代码仓库被克隆之前运行,因此它需要通过该代码仓库自己的蓝图来安装 (如下所示) 。该安装会在构建期间执行,并保留到快照中,这样其他所有代码仓库之后都可以使用它。 -
post-build是多代码仓库设置的核心价值所在。 它会在每个代码仓库都完成克隆和设置后运行,因此只有在这里,你才能验证整个技术栈能否一起正常启动。非零退出码会导致构建失败,因此你会在构建阶段就发现损坏的技术栈,而不是在会话进行到一半时才发现。参见post-build。 -
**secrets 应归属于组织,**而不是每个代码仓库。组织蓝图的 Secrets 选项卡中的一个
ACME_REGISTRY_TOKEN就可以供每个代码仓库的bundle install和npm install使用。
代码仓库蓝图
acme-devtools (repository blueprint)
acme-portal (repository blueprint)
acme-web、acme-sso 和 acme-events 的结构相同:各自都有一个用于安装自身依赖的 maintenance 步骤,以及针对各自 lint、测试和启动命令的 knowledge 条目。
Knowledge 按代码仓库隔离。 配置了五个代码仓库后,在
acme-portal 中工作的会话只能看到该 portal 的 Knowledge 条目,以及组织和企业级 Knowledge——看不到 acme-web 的条目。因此,每个代码仓库都应有自己的蓝图,即使它的 maintenance 部分只有一行。如果你的服务位于 monorepo 中
第 3 阶段:多个组织——企业蓝图
- 所有流量都必须通过企业代理,并使用内部证书颁发机构。
- 所有软件包都必须来自 Artifactory,绝不能来自公共仓库。
- 每个环境都必须安装公司的依赖项扫描和密钥扫描工具。
- 全公司统一使用 Python 3.12 和 Node.js 20,没有任何例外。
Devin's base environment (enterprise blueprint)
ARTIFACTORY_TOKEN 是一个企业级 secret,只需在 设置 > Devin 的基础环境 > Secrets 中定义一次,即可在所有组织的每次 build 和每个 session 中使用。该证书是一个文件附件,会以 $FILE_ACME_CA_CERT 的形式提供给 build。
现在各层级分别负责什么
第 2 阶段中的 Payments 组织蓝图会继续工作,完全无需更改。只是因为企业层级已经完成了这些工作,它不再需要安装 Python 或配置软件包仓库。Data 组织蓝图会安装 Spark 和 JDK,而 Payments 根本不会看到这些。代码仓库蓝图保持不变。
如何运作
- 将 Python 从 3.12 升级到 3.13 只需改动一行,再进行一次企业范围重建,变更就会级联到所有组织。
- 当某个团队需要不同的凭据时——例如,Data 组织有自己的 Artifactory 域——该团队只需定义一个同名的组织 secret,即可覆盖企业 secret。
- 若要在各组织中逐步 rollout 此变更,请参阅迁移你的企业。
决定某项内容该放在哪里
1
公司里的每个组织都需要它吗?
→ 企业蓝图。 证书、代理、内部注册表、指定的运行时、安全工具,以及公司范围内的 secrets。
2
这个组织里有两个或更多代码仓库需要它吗?
→ 组织蓝图。 Docker、共享的开发 CLI、本地主机名、跨代码仓库的服务编排,以及注册表凭据。在
post-build 中验证组装好的整套环境。3
是否只有这个代码仓库需要它?
→ 代码仓库蓝图。 依赖安装、迁移,以及与其 lint、test 和启动命令相关的
knowledge 条目。4
它是事实信息,而不是要运行的命令吗?
→
knowledge,放在它适用的层级。它永远不会被执行;它会被加载到 Devin 上下文中。- 把所有内容都放到某一个代码仓库的蓝图里。 其他代码仓库就拿不到 knowledge 条目,而且只要有一个步骤出问题,整个设置看起来都会不健康。
- 在每个代码仓库里重复配置共享工具。 如果两个代码仓库安装了同一个全局工具的不同版本,最后运行的那个会覆盖前面的。应改为把这个工具放到组织蓝图中。
- 跳过跨代码仓库验证。 如果你的代码仓库只有配合起来才能正常工作,那么
post-build是唯一能在会话开始前 (而不是进行中) 证明这一点的地方。
- 声明式配置 — 构建顺序、快照和故障排查
- 蓝图参考 — 所有字段说明,包括
post-build和clone - 模板库 — 可按语言和注册表直接复制使用的蓝图
- 工作区和 monorepo — monorepo 场景下对应第 2 阶段的内容
- 企业环境概览 — 第 3 阶段的完整详解

