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 内容也也许纷歧致。假如维护不妥，轻易造成两个分支不同越来越大，不易归并

方案三：多分支

正常流程

（编辑：湖南网）

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