Spark 灰度发布在十万级节点上的成功实践 CI CD

原创文章，转载请务必将下面这段话置于文章开头处。
本文转发自技术世界，原文链接　http://www.jasongj.com/spark/ci_cd/

本文所述内容基于某顶级互联网公司数万节点下 Spark 的 CI 与 CD & CD 实践。为了提高本文内容的可借鉴性，隐去了公司特有内容，只保留通用部分

Spark CI 持续集成实践

CI 介绍

持续集成是指，及时地将最新开发的且经过测试的代码集成到主干分支中。

持续集成的优点

• 快速发现错误 每次更新都及时集成到主干分支中，并进行测试，可以快速发现错误，方便定位错误
• 避免子分支大幅偏离主干分支 主干在不断更新，如果不经常集成，会产生后期集成难度变大，甚至难以集成，并造成不同开发人员间不必要的重复开发
• 为快速迭代提供保障 持续集成为后文介绍的持续发布与持续部署提供了保证

Spark CI 实践

目前主流的代码管理工具有，Github、Gitlab等。本文所介绍的内容中，所有代码均托管于私有的 Gitlab 中。

鉴于 Jenkins 几乎是 CI 事实上的标准，本文介绍的 Spark CI CD & CD 实践均基于 Jenkins 与 Gitlab。

Spark 源码保存在 spark-src.git 库中。

由于已有部署系统支持 Git，因此可将集成后的 distribution 保存到 Gitlab 的发布库（spark-bin.git）中。

每次开发人员提交代码后，均通过 Gitlab 发起一个 Merge Requet （相当于 Gitlab 的 Pull Request）

每当有 MR 被创建，或者被更新，Gitlab 通过 Webhook 通知 Jenkins 基于该 MR 最新代码进行 build。该 build 过程包含了

• 编译 Spark 所有 module
• 执行 Spark 所有单元测试
• 执行性能测试
• 检查测试结果。如果有任意测试用例失败，或者性能测试结果明显差于上一次测试，则 Jenkins 构建失败

Jenkins 将 build 结果通知 Gitlab，只有 Jenkins 构建成功，Gitlab 的 MR 页面才允许 Merge。否则 Gitlab 不允许 Merge

另外，还需人工进行 Code Review。只有两个以上的 Reviewer 通过，才能进行最终 Merge

所有测试与 Reivew 通过后，通过 Gitlab Merge 功能自动将代码 Fast forward Merge 到目标分支中

该流程保证了

• 所有合并进目标分支中的代码都经过了单元测试（白盒测试）与性能测试（黑盒测试）
• 每次发起 MR 后都会及时自动发起测试，方便及时发现问题
• 所有代码更新都能及时合并进目标分支

Spark CD 持续交付

CD 持续交付介绍

持续交付是指，及时地将软件的新版本，交付给质量保障团队或者用户，以供评审。持续交付可看作是持续集成的下一步。它强调的是，不管怎么更新，软件都是可随时交付的。

这一阶段的评审，一般是将上文集成后的软件部署到尽可能贴近生产环境的 Staging 环境中，并使用贴近真实场景的用法（或者流量）进行测试。

持续发布的优点

• 快速发布 有了持续集成与持续发布，可快速将最新功能发布出来，也可快速修复已知 bug
• 快速迭代 由于发布及时，可以快速判断产品是否符合产品经理的预期或者是否能满足用户的需求

Spark CD 持续发布实践

这里有提供三种方案，供读者参考。推荐方案三

方案一：单分支

正常流程

如下图所示，基于单分支的 Spark 持续交付方案如下

• 所有开发都在 spark-src.git/dev（即 spark-src.git 的 dev branch） 上进行
• 每周一将当前最新代码打包，放进 spark-bin.git/dev 的 spark-${ build # }（如图中第 2 周的 spark-72）文件夹内
• spark-prod 指向当前 spark-dev 指向的文件夹（如图中的 spark-71 ）
• spark-dev 指向 spark-${ build # }（如图中的 spark-72）
• 自动将 spark-bin.git 最新内容上线到 Staging 环境，并使用 spark-dev 进行测试
• spark-prod 比 spark-dev 晚一周（一个 release 周期），这一周用于 Staging 环境中测试