34 | 快速构建持续交付系统（一）：需求分析
王潇俊
该思维导图由 AI 生成，仅供参考
从今天这一篇文章开始，我们就进入这个专栏的最后一个系列：实践案例系列了。在这个系列里，我将通过 4 篇文章，以实际操作为主，带你快速构建一套持续交付系统。
当然，首先我们要做的是，一起整理一下思路，看看我们的系统具体要满足哪些实际的需求，需要具备什么功能。然后，建立需求的锚点，根据这些锚点，展开具体的搭建工作。
因此，在这篇文章中，我会以先介绍模拟团队和项目，再提出具体持续交付需求的思路，罗列一些要模拟的背景，并为你解说这些场景。这样做，可以帮助你在后面的三篇实践文章中找到对应的需求点，也可以让你与现在团队的持续交付体系作一番比较，找到相通之处，从而加深你对持续交付体系的理解。
模拟团队介绍
我在第 7 篇文章《“两个披萨”团队的代码管理实际案例》中，和你分享了“两个披萨”团队的代码管理实践。基本上，我们可以把一个这样的团队看作是一个微型研发团队。虽然这样规模的一个团队也可以很好地运用我们即将搭建的持续交付系统，但是因为过于理想化而缺乏了典型性。
所以，为了更全面地介绍持续交付系统的搭建过程，我将要模拟的团队规模扩大至 3 个“两个披萨”团队的大小。即，整个产品的研发，需要由这 3 个团队合作完成。这 3 个团队的分工，如下图所示：
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文介绍了如何快速构建一套持续交付系统，通过模拟团队和项目，提出了持续交付的需求和功能。文章首先介绍了模拟团队的情况，包括3个团队的分工和依赖关系，以及模拟系统的架构形式。接着详细介绍了模拟团队对持续交付流水线的需求，包括代码与配置管理、构建与集成、打包与发布、自动化测试等方面的需求。其中涉及了代码合并、集成编译、构建产物记录、打包发布环境需求、自动化测试平台选择等内容。整体来看，本文通过实际案例，深入浅出地介绍了持续交付系统的构建过程，对于需要构建持续交付系统的读者具有一定的指导意义。文章中还提出了一些思考题，引发读者对于实际项目中团队规模和持续交付体系需求的思考。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《持续交付 36 讲》，新⼈⾸单¥59
《持续交付 36 讲》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(2)
- 最新
- 精选
死后的天空老师，自动化测试TestNG我看了一下，现在的公司需求因为会变动略微有一些频繁，这部分代码的工作量有没有一个大体的比例，比如：一个接口的工作量和TestNG编写工作量的大体比例。作者回复: 这个问题真的很难，一般测试会有分层和分单元的做法，架构上分层，比如API的覆盖率要有标准，分单元就是找到功能的边界，对不同功能进行testing的编写，其实简单说还是先做好解耦，测试其实一样的 至于工作量的比例，其实不好讲，因为工作还是要100%做踏实，人员比例的话，一般测试开发比为5:1吧
2018-09-214
Roway
开发测试比5:1？2019-05-152
收起评论
