将开发流水线视为生产系统
开发流水线是一个生产系统
软件开发团队通常将面向客户的生产环境故障置于首位，但却经常将自身开发工具、构建系统和 QA 环境的故障视为次要问题。然而，对于负责交付价值的开发人员和测试人员来说，开发流水线是一个生产系统。当流水线中断时，团队交付软件的能力就会停止，从而为内部组织造成了功能性的生产故障。
识别开发流水线的组件
要将流水线视为生产系统，团队必须首先识别促进从客户需求到交付功能的每一个组件。这些关键路径组件包括：
- 需求跟踪： 问题报告和变更请求系统（例如，GitHub Issues, Jira）。
- 本地开发工具： IDEs, 构建工具（Gradle, Maven），包仓库（npm, Maven Central），本地数据库和容器。
- 自动化基础设施： CI/CD 工具，例如 Jenkins 和 GitHub Actions。
- 质量门禁： 测试套件和 QA 服务器。任何导致无法部署到生产环境的失败测试套件或离线 QA 服务器都是关键故障点。
流水线故障对交付的影响
当开发流水线的核心组件发生故障时，结果是价值交付的完全停滞。如果代码无法编译或测试无法运行，团队就无法生产可用的软件。在制造业中，这相当于流水线故障，由于闲置劳动力的成本极高，因此需要使用广泛的流程和 SLA 来最大限度地减少停机时间。
基础设施即生产
从运维的角度来看，随着技术栈的向下移动，“生产”的定义也在扩大。虽然产品开发人员将面向客户的系统视为生产环境，但基础设施和运维团队必须将开发和测试环境视为生产环境，因为它们的故障可能会使数百名开发人员陷入瘫痪。
对于我们这些从事基础设施运维的人来说，开发和测试实际上也是生产环境……如果我们搞砸了开发或测试环境，一百名开发人员就无法工作并开始尖叫。
反对观点与风险管理
虽然将流水线视为生产环境会增加紧迫性，但它也引入了必须管理的特定权衡和风险。
优先级决策困境
有人认为“生产”这一标签是对术语的误用，认为损坏的 IDE 或构建工具是“开发系统故障”而非生产故障。主要的批评意见是，修复流水线的紧迫性应该取决于成本效益分析，而不是采取“全体人员待命”的政策。例如，周末发生的流水线故障可能不需要像面向客户的故障那样立即响应。
将热修复与流水线解耦
对于将流水线视为生产环境的团队来说，一个关键的架构要求是能够为紧急热修复绕过标准流水线。如果开发流水线中断，团队仍应能够恢复面向客户的生产系统。
你应该有一种方法，可以绕过你的开发流水线来部署代码的热修复，以防在需要修复生产环境时开发流水线发生故障。
流水线安全与写入权限范围
将流水线视为生产环境也需要审计流水线的权限。如果部署工具对生产目录具有不受限制的写入和删除权限，那么流水线中的配置错误可能会导致灾难性的数据丢失，其程度将超过简单的工具停机。
流水线稳定性策略
为确保开发流水线保持为一个可靠的生产系统，团队可以采用几种稳定性模式：
- 依赖项锁定： 使用工具来冻结并锁定 Docker 镜像、操作系统包和特定语言的依赖项，以防止第三方故障或“被撤回”的包破坏构建。
- 低依赖回滚： 建立一种不依赖于 CI/CD 流水线的回滚机制。这确保了如果流水线本身是导致故障的原因，系统仍可以恢复到已知的良好状态。
- 开发者体验 (DevEx) 团队： 在大型组织中，专门的开发者体验或工具团队可以将流水线作为一类产品进行管理，并为内部工具提供 SLA。