DevOps - 从渐进式交付说起（含实践 Demo）

作者：CODING - 王炜

1. 开篇

如果让你主导一款千万、甚至亿级用户产品的功能迭代，你会怎么做？你需要面对的挑战可能来自于：

商业战略的变化带来新的产品诉求，而产品的任何改动哪怕仅是界面调整，都将面临无数存量用户的挑战

这时候，作为产品负责人，你会选择稳定压倒一切？还是自我革新，继续追求用户和市场的价值呢？笔者通过对 Facebook、Twitter 等互联网巨头的调研，试图窥探他们在瞬息万变的市场中仍然保持“稳定”迭代的秘密 - 渐进式交付

通过本篇文章，你将收获：

1. 什么是渐进式交付，为什么 DevOps 能够天然与其结合
2. 为什么渐进式交付能赋予大规模组织下的产品持续交付及稳定迭代的能力
3. 小项目，大项目同样适用的实践经验

2. 什么是渐进式交付

移动互联网时代的爆发，诞生了一大批巨型互联网企业和项目，部分大型项目的技术复杂程度和组织复杂程度甚至不亚于传统的工业项目，为了实现对这些项目的管理和迭代，我们试图将目光投向已经完成工业革命的传统工业寻找答案。

而“渐进式交付”一词最早起源于大型、复杂的工业化项目，比如：铁路、汽车和军事产业、新基建的 5G 网络产业等等。

它和 DevOps 的目标一致，试图将复杂的工程化项目进行分阶段拆解，通过持续进行小型迭代闭环，降低交付成本和节约交付时间

可查询的资料显示，“渐进式交付”流行于互联网产品是在近两年 Kubernetes 以及云原生大规模使用之后。这两项技术的出现，为“渐进式交付”在互联网的应用提供了基础设施和实现方法。

DevOps 是“渐进式交付”的实现手段，而其中的“流水线”为“渐进式交付”提供了实现途径

在产品的迭代过程，可以将“渐进式交付”的具体行为附着在“流水线”中，将整条交付“流水线”看做是产品迭代的一个过程和一次“渐进式交付”周期。

说了这么多“渐进式交付”的理论基础，在实践中又是以哪些技术方法落地呢？

1. A/B 测试
2. 金丝雀 / 灰度发布

以 Facebook 为例，每次发布重大功能，都会经历一次典型的“渐进式交付”过程：

1. 迭代发布
2. 公司全员 A/B 测试
3. 特定用户 A/B 测试
4. 灰度发布
5. 全量发布

这种渐进式交付的好处是，对于新迭代正式推向市场前提供了灰度用户的数据支撑，帮助决策者充分了解用户倾向和市场诉求。

在“渐进式交付”的过程中，A/B 测试环节以及灰度发布环节都可以根据用户数据和市场反馈决定是否进入全量发布，这种方式既能够保证迭代敏捷进行，又能够保证迭代的用户和市场安全性。

2.1 A/B 测试

例如通过对用户画像中地理位置和性别组合条件进行 A/B 测试，使其访问新版本，而其他的用户则继续访问旧版。一段时间后，研究用户行为数据和用户体验报告，决定功能是否继续进入下一个发布环节。

2.2 金丝雀 / 灰度发布

使用特定分流技术使流量由新老版本共同承担，如典型的“MurmurHash”算法

3. 技术价值和商业价值

从原理上来看，这些技术并不是多么新的技术，比如 A/B 测试，我们用最原始的方式：业务代码增加逻辑判断条件也可实现，但为什么没有大规模运用呢？

原因很简单：纯业务代码的实现依赖于技术开发，需求方无法自主控制 A/B 测试的环境和条件，这种过度依赖于技术开发并不能带来规模化的运用。

我们需要的是一种完全脱离业务代码的实现方式，最好能以自动化/半自动化实现，并且尽量能把这个动作加入到已有的内部流程内

现在，有了云原生和 Kubernetes 的支持，结合 DevOps 的流水线，自动化的渐进式交付成为了可能。

我们参考 Facebook 的发布方式，设计了这个 Pipeline Demo

它主要实现了：

1. 提交代码后自动执行单元测试，并构建 Docker 镜像
2. 将 Docker 镜像推送到私有制品库，自动触发流水线
3. 执行 K8S Job Migrate 数据库（如果有改动），并部署新版到预发布环境
4. 人工确认：发布生产环境前是否进行 A/B 测试
5. A/B 测试通过后，设置灰度发布的比例，自动灰度发布
6. 人工确认：是否全量发布生产环境
7. 生产环境自动配置限流和熔断策略，保证生产稳定

最终实现的效果图：

1. 提交代码后自动构建镜像、单元测试、推送到镜像仓库并触发 CD 流水线。

2. 执行 K8S Job 对预发布