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

在生产环境中发现了 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 周期的测试，稳定性强

Cons.

• hot fix 时，使用 cherry-pick，但 spark-src.git/dev(包含 commit 1、2、3、4、5) 与 spark-src.git/prod(包含 commit 1) 的 base 不一样，有发生冲突的风险。一旦发生冲突，便需人工介入
• hot fix 后再从 spark-src.git/dev 合并 commit 到 spark-src.git/prod 时需要使用 rebase 而不能直接 fast-forward merge。而该 rebase 可能再次发生冲突
• bug fix 修复的是当前 spark-bin.git/dev的 bug，即图中的 commit 1、2、3、4 后的 bug，而 bug fix commit 即 commit 9 的 base 是 commit 5，存在一定程度的不一致
• bug fix 后，第 3 周时，最新的 spark-bin.git/dev 包含了 bug fix，而最新的 spark-bin.git/prod 未包含该 bugfix (它只包含了 commit 2、3、4 而不包含 commit 5、9)。只有到第 4 周，spark-bin.git/prod 才包含该 bugfix。也即 Staging 环境中发现的 bug，需要在一周多(最多两周)才能在 prod 环境中被修复。换言之，Staging 环境中检测出的 bug，仍然会继续出现在下一个生产环境的 release 中
• spark-src.git/dev 与 spark-src.git/prod 中包含的 commit 数一致(因为只允许 fast-forward merge)，内容也最终一致。但是 commit 顺序不一致，且各 commit 内容也可能不一致。如果维护不当，容易造成两个分支差别越来越大，不易合并

方案三：多分支

正常流程

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

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