Skip to main content
蓝图分为三个层级——代码仓库、组织和企业——最常见的问题是:这应该放在哪一层? 本页将通过一家虚构公司 ACME Corp 的三个成长阶段来回答这个问题。每个阶段都只会引入一个新问题,而这个问题都会由上一个层级来解决。请直接跳转到最符合你公司情况的阶段。
先给出一个经验法则:代码仓库蓝图用于安装项目依赖,组织蓝图用于安装多个代码仓库共享的内容,而企业蓝图用于安装每个组织都必须具备的内容。 各层级采用叠加方式,并按自上而下的顺序运行:企业 → 组织 → 克隆代码仓库 → 代码仓库。

第 1 阶段:一个代码仓库

ACME 有一个产品:acme-web,这是一个使用 Postgres 和 Redis 的 Rails 应用程序。两个工程师,共用一个代码仓库。此时还没有任何需要共享的内容,所以所有内容都放在代码仓库蓝图中 他们在 设置 > 环境 > 蓝图 > 添加 中添加这个代码仓库,打开其编辑器,并编写:
acme-web (repository blueprint)
这就是全部配置。保存后会触发一次构建,此后每个会话启动时都会自动安装好 Ruby、启动 Postgres、装好 gems,并完成数据库迁移。 为什么还不使用组织蓝图? 只服务于一个代码仓库的组织蓝图只是徒增一层间接。等到第二个代码仓库也需要同样配置时再使用。
ACME 不是手动编写这些内容的。他们只需让 Devin “为这个代码仓库设置你的环境”,审查建议卡片,然后点击 批准。请参阅快速开始

第 2 阶段:多个共享依赖的代码仓库

两年后,ACME 有五个代码仓库: 这是一个很有代表性的场景,因为这些代码仓库并不是彼此独立的:如果没有安装 acme-devtools,且 acme-sso 没有运行,那么在 acme-portal 里就无法开展任何有意义的工作。这就引出了两个问题。

“每个应用程序一个蓝图,还是只为开发 CLI 配一个蓝图?”

两者都需要——用途不同。 Devin 会构建一个快照,其中包含所有已配置的代码仓库,所以这不是非此即彼的选择:
  • 全部五个代码仓库添加到环境中,这样它们都会被克隆到快照中。
  • 跨代码仓库共享的 setup统一放在组织蓝图中:语言运行时环境、Docker、本地主机名,以及内部 registry 的凭据。
  • 为每个代码仓库分别提供自己的代码仓库蓝图,用于管理各自的依赖,以及各自的 knowledge 条目 (lint、test 和 startup 命令) 。
下面说明为什么你不应该把所有内容都塞进 acme-devtools 蓝图:代码仓库蓝图会在所有代码仓库都克隆完成后运行,但其中的步骤会在对应代码仓库的目录中执行,而且其中的 knowledge 条目只有在 Devin 处理该代码仓库时才会加载。如果由 acme-devtools 安装所有内容,那么在 acme-portal 中工作的会话将看不到任何 portal 的 lint 和 test 命令;而且只要 acme-devtools 的某个步骤失败,其他四个代码仓库表面上看起来正常,实际上却无法使用。

组织蓝图

Organization-wide setup
有三点需要注意:
  1. initializemaintenance Docker、运行时和主机名属于一次性的系统设置,因此应放在 initialize 中。注册表凭据应在每次定期构建时刷新,因此应放在 maintenance 中。 这里特意没有包含 acme CLI 本身。它位于 acme-devtools 中,而组织级步骤会在任何代码仓库被克隆之前运行,因此它需要通过该代码仓库自己的蓝图来安装 (如下所示) 。该安装会在构建期间执行,并保留到快照中,这样其他所有代码仓库之后都可以使用它。
  2. post-build 是多代码仓库设置的核心价值所在。 它会在每个代码仓库都完成克隆和设置后运行,因此只有在这里,你才能验证整个技术栈能否一起正常启动。非零退出码会导致构建失败,因此你会在构建阶段就发现损坏的技术栈,而不是在会话进行到一半时才发现。参见 post-build
  3. **secrets 应归属于组织,**而不是每个代码仓库。组织蓝图的 Secrets 选项卡中的一个 ACME_REGISTRY_TOKEN 就可以供每个代码仓库的 bundle installnpm install 使用。
顺序陷阱:组织级 initializemaintenance 都会在代码仓库被克隆之前运行 (参见构建顺序) 。任何需要已检出源代码的内容——例如位于你的某个代码仓库内部的 CLI——都必须放在该代码仓库自己的蓝图中,或放在 post-build 中,而不能放在组织级 maintenance 中。只有当你可以从已发布的制品 (例如 tarball、package 或 container image) 安装它时,才应将其保留在组织这一层级。

代码仓库蓝图

每个代码仓库蓝图都很精简,因为所有共享内容都已现成可用:
acme-devtools (repository blueprint)
acme-portal (repository blueprint)
acme-webacme-ssoacme-events 的结构相同:各自都有一个用于安装自身依赖的 maintenance 步骤,以及针对各自 lint、测试和启动命令的 knowledge 条目。
acme-devtools 排在代码仓库列表第一位。代码仓库蓝图会按 Settings 中显示的顺序运行,因此,提供共享 CLI 的代码仓库应先于调用它的代码仓库完成设置。
Knowledge 按代码仓库隔离。 配置了五个代码仓库后,在 acme-portal 中工作的会话只能看到该 portal 的 Knowledge 条目,以及组织和企业级 Knowledge——看不到 acme-web 的条目。因此,每个代码仓库都应有自己的蓝图,即使它的 maintenance 部分只有一行。
由于 acme CLI 已经知道如何运行所有内容,这些蓝图中最有价值的部分是 knowledge 部分:它会告诉 Devin 该调用哪个 CLI 命令。如果你们有内部文档搜索,也可以将它指向那里。

如果你的服务位于 monorepo 中

思路是一样的,只是下沉一个层级:使用 工作区,在单个代码仓库内为每个包提供各自作用域内的设置和 Knowledge,而不是为每个代码仓库分别使用一个蓝图。

第 3 阶段:多个组织——企业蓝图

ACME 现在有 400 名工程师。Platform、Payments 和 Data 各自都有自己的 Devin 组织,拥有各自独立的代码仓库、成员和快照。安全团队提出了一些适用于所有组织的要求:
  • 所有流量都必须通过企业代理,并使用内部证书颁发机构。
  • 所有软件包都必须来自 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 是唯一能在会话开始前 (而不是进行中) 证明这一点的地方。