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

（编辑：网站开发网_马鞍山站长网）

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