译文
译自西班牙语原文，以原文为规范文本。 状态：草稿，待人工审校。如有歧义，以西班牙语原文为准。
分支、环境与发布版本¶
本页说明一个声明采用 SCAFFOLD 0.1 的项目如何将工作从已规划的工作项推进到已部署的发布版本，又如何从发布版本回溯到工作项。本页只是解释：规范位于要求之中，本页不增加任何义务。分支、工具和环境的名称均为虚构示例。
概要¶
- 每个分支和每个合并请求都引用一个工作项或一个批次 （R-025）。
- 主分支受到保护；工作分支生命周期短，且只属于一个批次 （R-026）。
- 每个环境都有用途、允许的最高数据价值、密钥来源以及部署者 （R-027）。
- 晋级的是同一个制品，以其指纹标识；配置另行注入 （R-028）。
- 发布版本具有已声明的版本号方案、不可变的标签，以及由其工作项生成的说明 （R-029）。
状态：SCAFFOLD 0.1 是已接受的版本（有已记录的人工决定级别）。本页没有把其中任何一项实践表述为已由自身度量证明；任何关于节省、稳定性或安全性的说法都需要度量（R-032）。
从工作项到发布版本，再返回¶
该周期有五个环节。每个环节都保存上一环节的标识符，因此查询可以沿链条向任一方向遍历。
| 环节 | 保存什么 | 如何关联 |
|---|---|---|
| 工作项 | 稳定的标识符，例如 TIE-12 |
实现它的批次、分支、变更和发布版本的列表 |
| 分支 | 带标识符的名称 | función/TIE-12-exportar-csv |
| 已提交的变更 | 带标识符的消息，以及位于机器可读字段中的署名 | 消息末尾的 trailer |
| 合并请求 | 工作项或批次、分支、负责人、助手、检查和审查者 | 请求的正文 |
| 发布版本 | 不可变的标签和发布说明 | 所含工作项的列表 |
有了这些关联，技术负责人就能回答两个问题：“1.4.0 发布版本包含哪些工作项？”以及“哪些变更实现了 TIE-12？”R-025 期望的证据是一个按发布版本列出工作项的查询；本页不规定由哪种工具来执行它。
分支命名约定¶
一个虚构项目，Ana 的网店，声明了这样的模式：
<tipo>/<identificador>-<resumen-corto>
función/TIE-12-exportar-csv
corrección/TIE-31-redondeo-de-totales
类型与 R-009 中的批次类型一致。标识符永远不会被复用（R-021）。如果代码托管服务或团队的文件系统不支持重音符号或斜杠，项目会声明一个变体（funcion-TIE-12-exportar-csv）；重要的是约定已写明，并且查询能够提取出标识符。
变更消息中的署名¶
R-003 要求能够将每项变更归属于一位负责人，并且在有助手参与时，归属于产出该变更的助手。R-025 要求该署名位于机器可读字段中。一种做法是使用 git 的 trailer：位于消息末尾、空行之后的 clave: valor 行，工具 git-interpret-trailers（2026 年 10 月 14 日查阅）可以读取和添加它们。
Exportar pedidos a CSV con separador configurable
Refs: TIE-12
Lote: L-2026-014
Co-authored-by: asistente-de-codigo <asistente-de-codigo@ejemplo.invalid>
Responsable: Ana
Co-authored-by: 是一种广为流传的约定；本页并不断言所有托管服务都识别它，也不断言它们的显示方式相同。键 Refs、Lote 和 Responsable 是本示例中的名称；项目自行选择并声明自己的键。残余风险（R-003）：所声明的署名可能有误或不完整；trailer 记录的是一项声明，并不验证它。
分支模型¶
R-026 要求仓库声明其模型：主分支、分支类型、谁负责合并，以及用哪些检查。示例中的模型：
| 要素 | 示例中的声明 |
|---|---|
| 主分支 | principal，受保护：只通过由人审查的合并请求接收变更 |
| 工作分支 | función/…、corrección/…；声明的最长生命周期为 3 个工作日（虚构数字） |
| 每个批次一个分支 | 分支只属于一个批次；有多个分支的批次须声明这一点 |
| 谁负责合并 | 技术负责人，或其指定的人。助手不得写入主分支，除非通过由人审查的合并请求；是否合并被列为关键的内容由人决定 |
| 检查 | 仓库自身的检查，在合并之前执行（R-010） |
两个助手不得同时写入同一个分支，已声明轮流的情形除外。这与写入区（R-001）相关：写入区划分路径，而分支划分历史线。这是两张不同的地图：一个分支可以触及多个区域（此时批次须指明其所有者，R-002），而一个区域也可以接收来自多个分支的变更。一种可行的模式是为每个助手分配各自独立的工作空间（同一仓库的不同工作副本或工作树），使其分支不与他人的分支混杂。这是一种组织上的选择；要求并不强制，它本身也不能保证不发生冲突。
来源与差异¶
Trunk Based Development，“Short-Lived Feature Branches”（2026 年 10 月 14 日查阅）描述了持续“几天”的功能分支，它们在完成时合并到公共分支。R-026 与之共享对短生命周期分支的偏好（作为“应当”，并声明最长生命周期），但并未采纳该技术的全部：它增加了对主分支的保护、人工审查以及每个分支只有一个写入者的规则。SCAFFOLD 与该来源在某一点上一致，并不使二者等同。
合并前的检查¶
合并批次之前，须执行仓库所声明的检查（R-010）。虚构示例：自动化测试、代码风格分析、检查契约与代码声明的是同一版本（R-006），以及工程层的排除清单（见下文）。完成定义包含这些检查（R-023）。助手不得自行合并或部署项目的关键影响目录所包含的内容；其余内容遵循所声明的检查。残余风险：检查和人工审查都可能遗漏错误。
环境¶
环境是软件运行的地方。R-027 要求为每个环境声明：用途、数据的最高分级、密钥来源、谁可以部署，以及准入检查。分级使用项目所声明的、有名称且取值明确的等级（MILPA-R-003）。示例中的虚构等级：公开、内部、机密、关键（由低到高）。合成数据或匿名化数据是测试环境的一种实践，而不是等级中的层级。示例表（虚构）：
| 环境 | 用途 | 允许的最高价值 | 密钥 | 谁部署 |
|---|---|---|---|---|
| 本地 | 在工作者的机器上开发和测试 | 公开（合成数据） | 环境自有，无真实价值 | 工作者本人，包括其助手 |
| 集成 | 对每个分支执行自动检查 | 公开（合成数据） | 自有，保存在项目的密钥库中 | 持续集成流程 |
| 预生产 | 测试候选发布版本 | 内部（匿名化数据） | 自有，与生产环境不同 | 交付负责人 |
| 生产 | 为用户提供服务 | 关键 | 自有，仅部署流程可访问 | 交付负责人，经知情的人工确认 |
该表所说明的规则（R-027）：使用密钥的环境须拥有自己的密钥，不与其他环境共用；非生产环境不得接收超出其声明价值的真实数据，已记录的例外除外；部署到生产环境须列入关键影响目录。这种处理源自 ASILO-R-005（关键影响之前的人工审查），密钥则源自 ASILO-R-006。残余风险：数据副本可能经由未声明的途径离开其环境。
晋级同一制品¶
R-028 区分三件事：制品（构建的产物）、其配置（各环境不同）和部署。到达生产环境的，是通过检查的同一个制品，以其加密指纹标识，不会按环境重新构建。配置在部署时另行注入。
- 制品只构建一次，并计算其指纹。
- 检查针对该制品执行，而不是针对重新构建的产物。
- 每次晋级都记录指纹；若与已检查的指纹不一致，则不予晋级。
- 部署到生产环境之前，须有回滚计划。
- 部署时记录发布版本、指纹、环境、授权人和结果。
回滚（回到先前的制品）本身并不会撤销数据变更；这是 R-028 的残余风险，计划在适用时会提及。记录的格式见模板。
来源 The Twelve-Factor App，“V. Build, release, run”（2026 年 10 月 14 日查阅）区分了构建、发布（构建加配置）和运行，并不建议修改正在运行的代码。R-028 在这种区分上与之一致，但又增加了作为身份的指纹、回滚计划和部署记录，而该来源并未按这些措辞作出规定。SLSA（SLSA 1.2，即规范于 2026 年 10 月 14 日首先呈现的版本；当日查阅，未引用具体章节）是一个关于供应链完整性和构建来源的框架。SCAFFOLD 并不要求它；项目可以将其作为自己的配置来采用，而这种采用不能由遵循 R-028 推出。
作为关键影响的生产部署¶
项目将“部署到生产环境”列入其关键影响目录，该目录收录于章程（R-019）；R-027 要求它列在其中。助手可以准备制品、提出回滚计划并填写记录；部署所需的知情确认由人给出，通常是交付负责人，记录中写明授权人（R-028）。只对已列入目录的事项要求确认，是有意为之：ASILO-R-005 指出，对一切都要求确认会导致不加阅读就批准，R-010 沿用了这一点。
发布版本¶
R-029 要求四件事，示例按如下方式声明：
- 已声明的版本号方案。 Ana 的网店使用三个数字（主版本.次版本.补丁），并声明何种变更会提升哪一位：与已发布内容不兼容、新增功能、修复。
- 不可变的标签。 每个已发布的发布版本在版本控制中都有一个标签，该标签不会移到其他变更上；若有错误，则发布一个新的发布版本。
- 由工作项生成说明。 发布说明由所含的工作项生成，而不是凭记忆重写（见模板）。
- 标明不兼容的变更，以及授权该发布版本的人。
来源及其差异：
| 来源 | 提供什么 | 与 R-029 的差异 |
|---|---|---|
| Semantic Versioning 2.0.0（2026 年 10 月 14 日查阅） | 一种版本号方案，以及提升主版本、次版本和补丁的规则 | 这是一种可行的方案；R-029 只要求声明一种，无论是这一种还是其他 |
| Conventional Commits 1.0.0（2026 年 10 月 14 日查阅） | 一种变更消息约定，其类型与版本号提升相对应 | R-025 要求为署名提供机器可读字段；消息约定是另一种可选格式 |
| Keep a Changelog 1.1.0（1.1.0，其页面所声明的版本；2026 年 10 月 14 日查阅） | 按发布版本、面向人编写的变更文件格式 | R-029 要求说明由工作项生成；该格式可作为呈现方式，而不能作为来源 |
三者都不是强制的。选择其中一种并不能证明符合 SCAFFOLD。
紧急通道¶
当某项修复无法等待常规检查时，紧急通道须事先定义，使用时留下记录，并以事后审查收尾（R-013）。它并不免除 ASILO-R-005 的人工审查，该审查是事前进行的，或者在适用事先定义的紧急例外时，事后进行。被部署的制品就是通过检查的那一个；如果不同，则记录其指纹和被省略的内容（R-028），且该部署进入事后审查。虚构示例：交付负责人授权部署 TIE-40 的一项修复，测试有所精简；由一个人事先确认关键影响（或者，若适用紧急例外，则事后审查）；当天为事后审查创建一个工作项，并记录制品的指纹以及省略了哪些检查。残余风险：事后审查并不能撤销所有影响。
工程层的排除¶
区域、交接说明、批次和编程助手的配置属于构建，而不属于产品。R-011 要求它们不进入被部署的制品，并在已构建完成的制品上进行检查。示例：构建之后，一项检查遍历制品的内容，若发现交接说明文件夹则失败。残余风险：清单可能遗漏文件或内嵌的数据。该检查属于集成准入或晋级的一部分，由项目决定。
交付区域性变更¶
虚构示例：一个工作项更新图书馆使用的区域性内容包。验收标准可以包括正确的引用与摘要、技术兼容性，以及范围未覆盖、上下文改变和审查待完成等案例。项目声明自身的检查；集成之前记录实际结果（R-010、R-023）。
交付记录标明制品、区域性内容和所选配置。依照 R-028，晋级的制品保留其摘要，环境配置单独注入。如果区域性内容是运行时必需的依赖，按照设计它属于产品；R-011 的排除对象是仅用于工程的配置，例如区域、说明和助手配置，而不是一切被称作“上下文”的内容。
更新或回滚时，保留相关版本与引用、兼容性标准、结果及交付决策。回滚内容包本身不会撤销对数据产生的效果，也不会使先前的法律来源重新生效。计划说明这些边界及不兼容变更的处理。发布说明依据 R-029 关联工作；事件或回滚保留 R-032 规定的事后审查。共用指南区分这些记录、法律适用性与授权。
度量交付¶
R-032 要求声明度量哪些交付指标、如何度量以及多长周期度量一次。它不规定具体是哪些。一种做法是 DORA（2026 年 10 月 14 日查阅）的五项指标：变更的交付时间（change lead time）、部署频率（deployment frequency）、部署失败后的恢复时间（failed deployment recovery time）、变更失败率（change fail rate）和每次部署的返工率（deployment rework rate）。选择它们并不证明有所改进：R-032 要求在前后都进行度量才能断言有所改进，并提醒说，一项指标可以在结果并未改善的情况下得到改善。本页不提供参考数字。
Hypothesis 及什么能使其升级¶
| 论断 | 状态 | 能使其升级的验证 |
|---|---|---|
| 为每个助手分设独立工作空间的模式能减少分支之间的冲突 | Hypothesis（未度量） | 在真实项目中比较前后的合并冲突，并提供带日期的数据 |
| 分支名称足以在团队工具中提取标识符 | Hypothesis（取决于工具） | 在测试仓库上执行 R-025 的查询 |
托管服务对 Co-authored-by: 的解释是一致的 |
未作断言 | 查阅每个具体服务的现行文档 |
接下来阅读：小组、模板以及 SCAFFOLD 页面。