Spark灰度宣布在十万级节点上的实践

本文先容了顶级互联网公司数万节点下 Spark 的 CI 与 CD & CD 灰度宣布实践。包括怎样维护源代码，怎样维护 Release 多版本，开拓版与正式版，以及怎样实现灰度宣布，怎样举办 hotfix 等。为了进步本文内容的可小心性，隐去了公司特有内容，只保存通用部门。

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 情形中测试 

注：

• 蓝色圆形是正常 commit
• 垂直虚线是宣布时刻点，week 1、week 2、week 3、week 4
• 最上方玄色粗横线是源码时刻线
• 下方黄色粗横线是 release 时刻线
• 绿色方框是每周天生的 release，带 build #
• 蓝色方框是开拓版本的 symbolic
• 橘色方框是线上版本的 symbolic

bug fix

在 Staging 情形中发明 spark-dev 的 bug 时，修复及集成和交付方案如下：

• 假如在 Staging 情形中发明白 spark-dev 的 bug，且必必要修复(如不修复，会带到下次的 spark-prod 的 release 中)，则提交一个 commit，而且 commit message 包括 bugfix 字样(如图中玄色圆形 commit 9 所示)
• 该 bugfix 被 Merge 后，Jenkins 获得关照
• Jenkins 发明该 commit 是 bugfix，当即启动构建，天生spark-${ build # }(如图中的 spark-73)
• spark-dev 指向 spark-${ build # } (如图中的 spark-73 ) 

hot fix

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!