|
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 （编辑：湖南网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
