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

出产情形中发明 bug 时修复及交付方案如下：

• 假如发明线上版本(即 spark-prod)有题目，须实时修复，则提交一个 commit，而且 commit message 包括 hotfix 字样 (如图中赤色圆形 commit 9 所示)
• 该 hotfix 被 Merge 后，Jenkins 获得关照
• Jenkins 发明该 commit 是 hotfix，当即启动构建，天生 spark-${ build # }(如图中的 spark-73)
• spark-dev 与 spark-prod 均指向 spark-${ build # } (如图中的 spark-73 ) 

Pros.

• spark-src.git 与 spark-bin.git 都只有一个分支，维护利便
• spark-prod 落伍于 spark-dev 一周(一个 release)，意味着 spark-prod 都乐成通过了一周的 Staging 情形测试

Cons.

• 行使 spark-prod 与 spark-dev 两个 symbolic，假如要做灰度宣布，必要用户修改响应路径，本钱较高
• hotfix 时，引入了已往一周多(最多两周)未经 Staging 情形中通过 spark-dev 测试的 commit，增进了不确定性，也违反了全部非 hotfix commit 都颠末尾一个宣布周期测试的原则

方案二：两分支

正常流程

如下图所示，基于两分支的 Spark 一连交付方案如下：

• spark-src.git 与 spark-bin.git 均包括两个分支，即 dev branch 与 prod branch
• 全部正常开拓都在 spark-src.git/dev 长举办
• 每周一(假如是 weekly release)从 spark-src.git/dev 打包出一个 release 放进 spark-bin.git/dev 的 spark-${ build # } 文件夹内(如图中第 2 周上方的的 spark-2 )。它包括了之前全部的提交(commit 1、2、3、4)
• spark-bin.git/dev 的 spark 作为 symbolic 指向 spark-${ build # } 文件夹内(如图中第 2 周上方的的 spark-2)
• spark-src.git/prod 通过 fast-forward merge 将 spark-src.git/dev 一周前最后一个 commit 及之前的全部 commit 都 merge 过来(如图中第 2 周需将 commit 1 merge 过来)
• 将 spark-src.git/prod 打包出一个 release 放进 spark-bin.git/prod 的 spark-${ build # } 文件夹内(如图中第 2 周下方的的 spark-1 )
• spark-bin.git/prod 的 spark 作为 symbolic 指向 spark-${ build # } 

bug fix

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

• 在 spark-src.git/dev上提交一个 commit (如图中玄色的 commit 9)，且 commit message 包括 bugfix 字样
• Jenkins 发明该 commit 为 bugfix 后，当即构建，从 spark-src.git/dev 打包天生一个 release 并放进 spark-bin.git/dev 的 spark-${ build # } 文件夹内(如图中第二周与第三周之间上方的的 spark-3 )
• spark-bin.git/dev 中的 spark 作为 symbolic 指向 spark-${ build # } 

hot fix

在出产情形中发明白 prod 版本的 bug 时，修复及集成和交付方案如下：

• 在 spark-src.git/dev 上提交一个 commit(如图中赤色的 commit 9)，且 commit message 包括 hotfix 字样
• Jenkins 发明该 commit 为 hotfix 后，当即将 spark-src.git/dev 打包天生 release 并 commit 到 spark-bin.git/dev 的 spark-${ build # } (如图中上方的 spark-3 )文件夹内。 spark 作为 symbolic 指向该 spark-${ build # }
• 通过 cherry-pick 将 commit 9 double commit 到 spark-src.git/prod(如无斗嘴，则该流程全自动完成，无需人工参加。如产生斗嘴，通过告警体系关照开拓职员手工办理斗嘴后提交)
• 将 spark-src.git/prod 打包天生 release 并 commit 到 spark-bin.git/prod 的 spark-${ build # } (如图中下方的 spark-3 )文件夹内。spark作为 symbolic 指向该spark-${ build # } 

Pros.

• 无论是 dev 版照旧 prod 版，路径都是 spark。切换版对用户透明，无迁徙本钱
• 利便灰度宣布
• hotfix 不会引入未经测试的 commit，不变性更有保障
• prod 版落伍于 dev 版一周(一个 release 周期)，即 prod 颠末尾一个 release 周期的测试，不变性强

（编辑：湖南网）

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