|
Pros.
- 正常开发在 spark-src.git/master 上进行，Staging 环境的 bug fix 在 spark-src.git/dev 上进行，生产环境的 hot fix 在 spark-src.git/prod 上进行，清晰明了
- bug fix 提交时的 code base 与 Staging 环境使用版本的 code 完全一致，从而可保证 bug fix 的正确性
- bug fix 合并回 spark-src.git/master 时使用 rebase，从而保证了 spark-src.git/dev 与 spark-src.git/master 所有 commit 的顺序与内容的一致性，进而保证了这两个 branch 的一致性
- hot fix 提交时的 code base 与 生产环境使用版本的 code 完全一致，从而可保证 hot fix 的正确性
- hot fix 合并回 spark-src.git/master 时使用 rebase，从而保证了 spark-src.git/dev 与 spark-src.git/master 所有 commit 的顺序性及内容的一致性，进而保证了这两个 branch 的一致性
- 开发人员只需要专注于新 feature 的开发，bug fix 的提交，与 hot fix 的提交。所有的版本维护工作全部自动完成。只有当 bug fix 或 hot fix rebase 回 spark-src.git/master 发生冲突时才需人工介入
- spark-bin.git/dev 与 spark-bin.git/prod 将开发版本与生产版本分开，方便独立部署。而其路径统一，方便版本切换与灰度发布
Cons.
- 在本地 spark-src.git/master 提交时，须先 rebase 远程分支，而不应直接使用 merge。在本方案中，这不仅是最佳实践，还是硬性要求
- 虽然 bug fix 与 hot fix commit 都通过 rebase 进入 spark-src.git/master。但发生冲突时，需要相应修改 spark-src.git/master上后续 commit。如上图中，提交红色 commit 9 这一 hot fix 后，在 rebase 回 spark-src.git/master 时，如有冲突，可能需要修改 commit 2 或者 commit 3、4、5。该修改会造成本地解决完冲突后的版本与远程版本冲突，需要强制 push 回远程分支。该操作存在一定风险
Spark CD 持续部署
持续部署是指，软件通过评审后，自动部署到生产环境中。
Continuous Deploy
上述 Spark 持续发布实践的介绍都只到 "将 *** 提交到 spark-bin.git" 结束。可使用基于 git 的部署(为了性能和扩展性，一般不直接在待部署机器上使用 git pull --rebase，而是使用自研的上线方案，此处不展开)将该 release 上线到 Staging 环境或生产环境
该自动上线过程即是 Spark 持续部署的最后一环。
【编辑推荐】
- Spark性能优化：开发调优篇
- 大数据处理引擎Spark与Flink大比拼
- 对Spark的那些【魔改】
- 高性能Spark作业基础：你必须知道的调优原则及建议
- 大数据可视化工具圈里的春秋战国
【责任编辑：未丽燕 TEL：（010）68476606】
点赞 0 （编辑：好传媒网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
