阿里云云原生 DevOps

第 5 章结尾留了一个问题：技术栈都到位了，团队怎么保证每一次上线都又快又稳？这一章是因果链的最后一环——DevOps。

为什么需要 DevOps

传统开发流程里，需求、开发、测试、运维往往是四个割裂的环节，各管一段，中间靠人工交接。这种割裂会带来几个典型问题：

DevOps（Development + Operations）不是某一个工具，是一种打破"开发"和"运维"之间壁垒的文化和方法论：让写代码的人也对代码上线后跑得好不好负责，运行中的反馈也能及时回到下一轮开发。目标很直接：更快、更频繁、更可靠地交付软件。

DevOps 要落地，需要三个层面一起到位：

三者缺一不可：只改文化不上工具，自动化落不了地；只上工具不改协作方式，工具只是摆设。

流水线（Pipeline）把验证和发布串起来。CI 是持续集成（Continuous Integration）；CD 有持续交付（Continuous Delivery）和持续部署（Continuous Deployment）两种含义，区别在进入生产环境的这一步：

课程中的触发方式是：开发者接到新需求后，在代码仓库里创建一条特性分支（Feature Branch）并与需求对应；代码提交后，CI Server（如 Jenkins、云效 Flow）自动触发构建和测试流水线。分支策略可以不同，但频繁集成、自动验证和可重复发布是要保留的工程实践。

前面几章讲的容器、Kubernetes、微服务，给 DevOps 提出了新的要求：

应用从几个大单体拆成几百个微服务之后，每个服务都要有自己的 CI/CD 流水线，流水线数量和管理复杂度一下暴增
容器化之后，流水线不再只是"构建代码"，还要把"构建镜像、扫描镜像安全、推送到仓库"（呼应第 3 章的 ACR）也纳入进来
Kubernetes 的声明式 API 天然适合和 CD 结合——用 Git 仓库里的 YAML 作为集群状态的唯一事实来源，一旦 YAML 变化就自动同步到集群，这个理念通常被称为 GitOps

简单说：云原生时代的 DevOps，流水线要覆盖"代码 → 镜像 → Kubernetes 部署"这条更长的全链路，而不只是传统的"代码 → 服务器部署"。

如果需求管理用一个工具、代码托管用另一个工具、CI/CD 又是第三个工具，团队协作的信息还是散落在各处，交接环节并没有真正消失，只是从"人工交接"变成了"在不同工具之间来回切换"。一站式平台把需求、代码、构建、测试、部署、度量这几个环节串在同一个系统里，才能真正形成一个完整、可追溯的闭环。

和第 4 章 EDAS 一样，云效也不是从零设计的产品，而是阿里巴巴内部数万研发人员每天在用的同一套系统，产品化之后对外开放。

云效覆盖研发全生命周期的产品矩阵，比较核心的几个：

Projex（项目协作）：需求和任务管理，和钉钉组织打通
Codeup（代码管理）：四项核心功能——代码托管、代码评审、代码扫描、质量检测（注意：代码扫描属于 Codeup 而不是 Flow）
Flow（流水线）：自动化的 CI/CD 交付流水线，持续集成、持续验证、持续发布
Testhub（测试管理）：测试用例和测试流程管理
Packages（制品仓库）：构建产出的制品统一存放和分发
Insight（效能洞察）：研发过程的度量数据，帮团队看清楚流水线卡在哪个环节

这些产品串起来，覆盖的正是前面说的"需求 → 代码 → 构建 → 测试 → 制品 → 部署 → 度量"这条完整链路，并且和阿里云其他产品（ACR 镜像仓库、ACK 容器集群、云监控）深度集成，不用自己再拼凑一套工具链。

费用：云效基础版免费、不限人数（代码托管、流水线、项目协作、测试管理等基础功能都包含）；高级版 618 元/人/年（5人起售），增加代码安全加密、组织级效能报表、私有构建集群等企业级特性。

写到这里，第 1 章推的那条因果链正好完整地走了一遍：环境不一致 → 容器 → 编排 → 微服务 → Mesh 化 → Serverless → 消息队列解耦 → 限流降级和混沌工程 → 可观测性 → 最后是 DevOps 把整条交付链路本身也变成自动化的工程实践。