开发流水线也是生产系统
The development pipeline is a production system
软件开发者深知修复线上故障的紧迫性，却往往忽视开发工具、构建系统或 QA 环境的问题。但事实上，对于研发团队而言，开发流水线就是生产系统。一旦代码无法编译或测试环境宕机，团队就无法交付价值，这本质上就是一场生产事故。无论是 GitHub Issues、Jira 这样的工单系统，还是 IDE、Gradle、Maven 等构建工具，亦或是 Jenkins、GitHub Actions 等 CI/CD 工具，任何阻碍从需求到交付的环节故障，都应被视为最高优先级的生产中断。我们不能只关注面向客户的故障，而忽略了支撑我们构建服务的内部系统。
对于研发团队来说，开发流水线就是一场生产事故。
HN 评论区
87- lifeisstillgood
我恐怕不同意。
存在一个生产生态系统——我们称之为“酒店”。
它在运转，员工在其中工作，客户付费，它产生收入。
但它需要不断变更。需要建造新客房，厨师改变主意后厨房需要重新布局。
所以他们聘请了建筑师和建筑公司。这些公司规划变更，然后一台神奇的自动化机器人出现，建好额外的房间。
建筑公司拥有并负责这台机器人及其变更。
无法实施变更确实至关重要，但我不会称之为“生产”，因为酒店仍能正常运营。
业务与技术之间的大部分误解，其实是对“你是在为建筑公司工作，还是在为酒店工作”这一问题的误解。
- tetha
这是进入运维领域后反直觉的部分之一：如果你深入到栈的更底层，生产的范畴就会向开发扩展：
对于产品开发和运维人员来说，面向客户的系统就是生产环境。
而对于我们基础设施运维人员来说，开发和测试环境实际上也是生产环境。也许 SLA 更低，维护调度更容易，但如果开发或测试环境挂了，上百名开发者就无法工作，开始尖叫。
在基础设施运维团队内部，我们的配置管理测试和部署流水线就是生产系统。如果它们失效，基础设施运维人员就无法测试或向基础设施推出变更。
最近一个提供跨领域服务的开发团队就发现了这一点：他们的测试环境可能导致许多其他团队的工作停滞，因此他们必须对测试环境格外小心。
- wxw
根据我的经验，大多数大型公司都将无法发布代码（即无法部署到生产环境）视为故障。在 CI/CD 基础设施团队中轮值待命（on-call）相当普遍。
同意开发流水线的许多部分可能时好时坏。在大规模场景下，拥有一个专门的“开发者体验/工具”组织是很好的，尽管我见过即使有这种组织，结果也褒贬不一。
- donatj
> 如果 QA 服务器宕机，测试人员无法工作，团队就无法产出可用的软件。对 QA 团队而言，这就是一次生产故障。修复它应是最高优先级。
一个真诚的问题：这里还有人在软件行业工作且仍拥有专职 QA 团队吗？我们大约一年前裁掉了所有 QA 工程师，和朋友们及前同事聊天后，这似乎已成为全行业的趋势？
顺便说一句，我认为一名优秀的 QA 人员价值连城，这真是一个可怕的错误。我只是好奇是否还有人保留着 QA 团队。
- maciejgryka
我敢打赌，因无法快速发布而导致业务失败的故事，和因过度关注工具而非向客户交付价值而导致失败的故事一样多。这两种失败都很危险！而且根据你的市场、产品、团队等因素，该光谱上的不同位置才是合适的。
在某些地方，快速发布本身就是价值的一部分。在另一些地方，产品能运行并交付价值，而缓慢的发布（暗示例如手动发布流程）反而是一种特性。
这篇文章所倡导的观点当然是一个有效的视角，但在我看来，将其视为普遍真理则是一个错误。