specsfy-specialist-delivery-engineering

交付工程

适用场景

• 当项目有流水线（CI/CD 的 *.yml）、发布策略、环境间晋级流程或 rollout/rollback 计划时使用。
• 针对特定变更，在 rolling、blue-green、canary 或 feature flag 之间进行选择时也使用。
• 不用于 Swarm 集群内部的底层部署（请使用 $specsfy-specialist-docker-swarm），也不用于确定哪些信号能证明 rollout 状态良好（请使用 $specsfy-specialist-observability）——此处关注的是流水线设计和晋级策略。
• 当流水线处理生产凭据或发布已签名的制品时，与 $specsfy-specialist-application-security 配合使用。

流程

1. 进行完整发布或部署时，在 $specsfy-specialist-deploy 的指导下工作，并使用 $specsfy-specialist-versioning 准备的 SEMVER 来标记制品、变更日志和标签。
2. 在设计流水线前，梳理提交、制品、环境、所需审批以及各晋级环节的负责人。
3. 通过已纳入版本控制的 lockfiles，确保构建和测试可复现——切勿在构建时解析“最新”依赖。
4. 仅生成一次不可变制品，并在环境间晋级时不重新编译（在 staging 中测试的二进制文件必须与发布到 production 的文件逐位相同）。
5. 按作业隔离凭据、权限和信任边界——执行构建的作业不得持有发布到 production 的凭据。
6. 协调 schema migrations，确保在整个 rollout 窗口内，应用的旧版本和新版本保持兼容（expand/contract）。
7. 在首次正式部署前，定义 rollout 策略、客观的成功信号、暂停标准和 rollback 机制。
8. 以可审计的方式记录来源信息（制品的来源）、版本、测试证据和 rollout 结果。

惯例

• 遵循最小权限原则，使用临时凭据（OIDC/STS，而非长期静态 secret），并将流水线 actions/依赖固定到 hash 或确切版本，而非浮动标签（@latest、@main）。
• 不要针对每个环境重新构建制品；只构建一次，进行签名或生成 digest，然后晋级同一个不可变引用。
• 阻止不兼容的并发操作（同一服务不能同时进行两次部署），并禁止部署未通过完整测试流水线的提交。
• 通过基础设施即代码确保环境可复现；环境配置应置于制品之外（env vars、secret manager），绝不能嵌入构建产物。
• 在判定 rollout 完成前，必须执行功能性 smoke checks 并确保 observability 已启用——“部署无错误地结束”不等于“服务运行正常”。
• 将代码 rollback（恢复到之前的二进制文件）与数据 rollback（撤销已应用的 migration）视为不同的问题，并制定不同的计划——并非所有 migration 都能在不丢失数据的情况下撤销。
• 保留可审计的记录，注明由谁晋级了什么、何时晋级以及获得了哪些审批，同时绝不在日志或审计制品中记录 secret。

反模式

• 在每个环境中都重新构建镜像的流水线（在 staging 作业中执行 build，然后在生产作业中再次执行 build）：即使使用相同的 Dockerfile，在 staging 中测试的制品也无法保证与最终部署到生产环境的制品相同——解析为 "latest" 的依赖项或不同的缓存都会产生不同的二进制文件。
• 没有负责人或过期时间的功能标志：会积累无人记得用途的废弃标志，增加未经测试的组合范围。
• 在移除旧列的同一次部署中应用 schema migration：如果代码需要回滚，而回滚的应用版本要对已更改的 schema 运行，就会导致故障——先在一次部署中执行 expand（添加），之后确认没有旧版本再依赖该列时才执行 contract（移除）。
• 外部 fork 的 pull request 作业可以访问生产 Secret：外部 PR 上下文不应访问任何受保护环境的 Secret。

验证

• 对流水线进行 lint/静态验证，在安全分支上完整运行，并进行一次有意触发的故障测试（关键步骤失败时，流水线确实会停止，且不会提升制品）。
• 在项目采用这些实践时，验证制品摘要、SBOM 和签名/来源证明（attestation）。
• 在生产环境首次执行前，先在具有代表性的环境中完整演练 rollout 和 rollback——不要仅凭阅读提供商的配置就放心。
• 确认提供商中已配置审批关卡、分支保护和权限（不能只检查 workflow 文件，因为有 push 权限的人可以覆盖该文件）。
• 没有这些证据时，不要声称流水线“安全”或 rollout“已完成”；日志中没有错误并不能证明服务健康。

相关 Skills

• $specsfy-specialist-deploy 协调完整的 release 和 deploy；此 skill 负责流水线和制品提升。
• $specsfy-specialist-versioning 准备 SEMVER，并确保制品、变更日志、标签和提升环节中的版本号一致。
• $specsfy-specialist-ansible 在主机上应用幂等配置；此 skill 管控交付的提升、审批和来源证明。
• $specsfy-specialist-software-architecture 定义流水线在各环境中落实的边界和结构约束。
• $specsfy-specialist-observability 提供客观信号（错误、延迟、饱和度），用于决定继续、暂停还是回滚 rollout。
• $specsfy-specialist-docker-swarm 适用于部署目标为 Swarm 集群的情况——此 skill 设计流水线，直至制品提升环节；另一个 skill 在集群内执行 rollout。
• $specsfy-specialist-application-security 负责加固流水线凭据、供应链和制品签名。
• $specsfy-specialist-performance-engineering 适用于 rollout 需要在开放全部流量前建立性能基线的情况。
• $specsfy-specialist-gitflow 适用于项目声明采用 Gitflow 作为分支策略的情况——该 skill 提供正确的分支和标签（将 release/*/hotfix/* 合并到 main），此 skill 决定流水线如何响应它们。

阅读 references/standards.md，了解流水线的最低步骤、release 策略和供应链的比较，以及官方来源。