17 | 人多力量大vs.两个披萨原则，聊聊持续交付中的流水线模式
赵成
该思维导图由 AI 生成，仅供参考
在前面 5 期文章中，我们分别详细介绍了持续交付体系基础层面的建设，主要是多环境和配置管理，这些是持续交付自动化体系的基础，是跟我们实际的业务场景和特点强相关的，所以希望你一定要重视基础的建设。
本期文章是我们持续交付系列的第 6 篇文章，从本期开始，我们进入到交付流水线体系相关的内容介绍中。
持续交付流水线简要说明
从一个应用的代码提交开始，到发布线上的主要环节，整个流程串起来就是一个简化的流水线模式。如下图所示：
我们前面介绍了持续交付的多环境以及配置管理，而流水线模式的整个过程正是在这个基础上执行，所以它的某些环节和要素与我们的多环境是有一些交叉的。比如，功能测试会在线下相关的几个环境上完成，比如我们前面介绍到的开发联调环境、项目环境和集成测试环境。
但是，它们要达成的测试目的是不同的：对于非功能验收，我们会在线上的预发环境完成，因为预发环境更接近真实场景，所以像容量、性能、安全这些跟线上稳定性相关的能力验收，越接近真实环境，效果越好。
后面几期文章，我会结合我们的实践，分环节来介绍。本期文章我们先看项目需求分解和开发模式选择。
项目需求分解
持续交付我认为更多的是针对应用层面，所以项目需求分解这一部分，这里我们就不展开讲了。这里我们的工作重点，就是将项目管理中的需求与持续发布中的应用这二者很好地关联起来。
比较通用的做法，就是要求业务架构师在做需求分析和功能设计时，要针对一个需求进行拆分，最终拆分成一个个的功能点，这些功能点最终落实到一个个对应的应用中，对应的逻辑体现就是应用代码的一个 feature 分支。
如下图所示：
举个简单的例子，比如我们要做大促的优惠活动，同一店铺商品购满 500 元，可以使用 10 元店铺内优惠券，同时还可以使用 10 元全站优惠券。
这样一个需求最终拆解下来，可能需要店铺应用支持多优惠活动的叠加，同时下单应用和购物车应用在计算价格时也要设定相关的优惠逻辑，这一个需求可能就拆出三四个功能点。
这样做的好处就是，从一开始的需求管理维度，就确定了最终多个应用联调、测试以及最终发布的计划和协作方式，从而就会让我们明确同一个项目环境中到底需要部署哪些应用，这些应用的发布顺序怎样安排。
比如，如果 A 应用依赖 B 应用，那么 B 应用就必须优先发布。所以，上述这个过程对于项目进度管理、团队协作以及最终的发布计划都是有帮助的。
讲到这里，你是不是又进一步感受到了运维的重要性呢？
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
持续交付中的流水线模式是软件开发中的重要环节，本文从项目需求分解和开发模式选择两个方面展开讨论。在项目需求分解中，作者强调了将项目管理中的需求与持续发布中的应用很好地关联起来的重要性，通过拆分需求并将功能点落实到对应的应用中，明确了多个应用联调、测试以及最终发布的计划和协作方式。在开发模式选择方面，文章介绍了主干开发模式、gitflow开发模式和分支开发模式，并分析了它们的适用场景和实际操作中的选择原则。最终，结合对主干开发模式和gitflow开发模式的综合对比，作者认为分支开发模式简单清晰，在实际操作中更适合使用。 本文通过对持续交付流水线模式的相关内容进行了深入探讨，旨在帮助读者更好地理解持续交付中的关键环节和技术特点。通过对项目需求分解和开发模式选择的详细阐述，读者可以获得对持续交付流水线模式的全面认识，同时也能够在实际操作中更好地选择适合自身团队的开发模式。文章内容丰富，观点明晰，对于从事软件开发和持续交付的技术人员具有一定的参考价值。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《赵成的运维体系管理课》，新⼈⾸单¥59
《赵成的运维体系管理课》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(3)
- 最新
- 精选
唐😊 木木分支开发模式看起来很像gitflow模式少了devlope和hotfix分支。直接把master当dev分支，拉出的特性开发分支然后merge到release分支，release在经过测试合并到master分支。不知道这么看对不对。2019-06-144- 我在线一个需求拆分下来多个应用，但是有可能这些应用是由不同的团队在维护。这时候怎么协作呢2024-02-08归属地：四川
森馫鑫系统功能一直是按固定版本发布，因此基本都是选用了gitflow开发模式，不过对于新系统更加追求小步快走，在这个时候会用主干开发模式。2018-07-15
收起评论
