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

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 内容也可能不一致。如果维护不当，容易造成两个分支差别越来越大，不易合并

方案三：多分支

正常流程

（编辑：青岛站长网）

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