刘为红 置顶2018-07-05持续交付是从用户获取反馈后再通过持续集成不断改进的过程，持续部署又是持续交付的最后一公里，是不是可以理解为为持续交付=持续集成+持续部署，我们做持续交付就是要进行持续集成+持续部署，这三者的关系有点晕，希望老师解答一下作者回复: 应该这样理解，持续交付包含其他两者，但不是等于两者相加。就像我文中提到的，交付对象未必一定是最终用户，定期提测、修复、再提测，充分利用了测试资源，也是持续交付。千万不要认为一定要做到端到端完整才叫持续交付。持续的产出并持续的验证。这也是为什么我会说任何企业，任何人都可以去尝试持续交付的原因
6
2018-07-06看完文章，觉得公司的主要问题集中在持续集成和持续部署上。看完回复和评论内容，就觉得，三者互相渗透，没有绝对的对立。团队后台开发人员，总是以后台逻辑是个整体，需要统一编码结束后，方可测试，但是受交付进度的影响，测试人员往往压力很大。中间有试过，后台单个功能模块编码结束，测试人员测试没问题后，整体交付前，之前测试的模块又有新的问题，这样测试人员的积极性又没了，觉得还是都编码结束整体测试才比较好。小公司的效率问题，一直没办法提升，任重道远，作为管理新人，希望看完能有真正的理解与运用，为实际工作减少压力。 2 5
2018-07-06我想提前了解一个问题、携程是否做到开发提交代码即触发流水线流程、并且其中自动化测试是针对提交的这块代码做测试、如果做到了具体如何做，没做到原因是什么？作者回复: 携程的话，push2CI2CD都是做到的，静态扫描是针对新增代码的，但是自动化测试不是。另外自动化测试怎么只对提交的代码，我不知道怎么做到，可能也没人能知道：）比如我改了一个枚举，我真的不知道该怎么只测试这个commit的内容就算OK了，因为自动话测试本来就是讲求覆盖率，ut也是一样的
3
2018-07-05期待实际实施课程，目前正在犹豫是专门招一个有经验的CI/CD工程师还是在团队内培养，毕竟初期无法投入太多人力进行工具的搭建，目前也只能从意识上向团队推广，要以一种快速开发 快速提测 快速反馈 快速修复的理念开展工作，但没有工具的支撑又很担心人员出现负面情绪，反而降低了效率。 3
2018-07-05我在一家初创企业做小组leader，系统从单体到微服务，小组成员从两人到十人，规模不断扩大，系统越来越复杂。持续交付的技术工具了解很多，我们也在尝试一些实践。希望在这里得到老师的最佳实践经验，使我们少走弯路，提升整个团队的效率和满意度。 3
2018-07-05效率和质量是当前我们希望通过持续集成，持续交付来解决两个最棘手的问题。新开发的产品部署到用户现场已经上百套了，一直都没有一个稳定的版本。这也是困惑我许久的难题。 2
2019-12-27思考：最近遇到了这样的问题，项目开发经常是觉得没有问题了，结果要给人家看的时候，出问题了，没有一个真正的测试环境，代码管理也只是简单的用了git。我就在想，大公司的一整套开发流程是什么样的，从一个产品出生到开发到测试再到上线，然后看到了持续交付，简单了解后，不知道是不是想要的东西。看到这里，明白了！是我们需要的东西，简单来说，我觉得首先持续交付可以解决我们的项目管理规范化，不会再杂乱无章，其次，就是可以提高效率，同时也使得不论是个人还是团队，都能够更快成长。谢谢。 1
2018-12-16无论是横向的业务研发团队，还是纵向的技术框架团队。
我的理解是业务是纵向的，技术是横向的，你这句话是不是有问题作者回复: 嗯，确实是，感谢指出
1
2018-10-26问：你的团队最希望借助持续交付解决什么现实问题？答：我们团队的交付物是SDK，需要支持多种平台（win，Linux ，iOS，android），引入持续交付，现在能理解的，就是提升生产效率，让研发人员专注业务，提高产品质量。目前SDK产品经过2年的开发已成熟，但从开发到提测到测试到上线，全都是非常传统的复制粘贴方式，仅仅依靠人为编写的文字流程与文档规范去控制整个过程，可想这中间有多大的效率提升空间。以交测举例，原来需要开发在源码的若个build目录下拷贝文档，sdk，demo，按照规范组成产品包，手动提交到某个交测目录下，发邮件通知测试同事，整个过程需要1h，且容易出错。在简单使用Jenkins之后，源码的提交就会自动触发上述所有过程，只需1分钟，直接为研发用户带来效益。作者回复: 看起来棒棒的
1
2018-07-05嗯，终于等到第一篇。
我在一家初创公司做中层技术管理，面临项目交付业务压力大、项目交付速度要求高的困境，希望利用持续交付能有所建树作者回复: 坚持并持续改进，持续交付和重构其实一样，越痛苦的事，就越要多做，加油💪
1
2020-01-27有种观点是 持续集成，持续交付，持续部署，是三个递进的阶段。持续集成主要是编译，构建，单测等。持续交付是把代码交付到test环境给QA人员，测试之后达到一种可交付的状态，持续部署是部署线上环境让用户可以使用，请问这种说法合理吗
2019-11-03很好奇老师遇到过哪些“不可持续点”，希望有个参考列表。作者回复: 首先可以自动化但没有自动化的点
其次是需要人工判断的，是否可通过约定来解决
再有，不在控制能力之内的事情，可否异步处理
最后注意记录，回溯，幂等处理- 2019-06-02现在持续交付主要是想通过自动化来确保每次开发修改代码后没有影响到其他功能 。
2018-12-21持续集成，持续交付，持续部署三者之间是什么关系呢？作者回复: 文章里应该写清楚了吧……
- 2018-12-21关键词:持续交付，持续集成，持续部署
- 2018-11-19看留言中有人提到如何实现自动化测试只针对提交的代码做测试，我在以前的公司的时候，有考虑到往这个方面考虑。大概思路有两种：第一种是通过前期的运行测试后，会自动形成一个代码和测试用例的一个对应关系（这个是个难点，在我离开时尚未形成可行的方案），当下次代码提交后，会自动寻找修改代码对应的测试用例，只运行该部分测试用例。 第二种是在写测试用例的时候，手动分模块，当对应模块的代码修改后，就只运行对应模块的测试用例（手动选择）。 第二种方式是我们一直在操作的，但是这个比较粗糙，只能保证修改的模块的测试用例通过，当跨模块影响时，是无法辨别的。而第一种方式，系统会自动判断哪些测试用例会受影响，从而自动运行对应的测试用例即可。
2018-10-28从单个需求的角度来看，如果有一个大的需求，涉及到不同的部件或者说模块，怎么能够保证各个部件的进度是统一的，不影响其他需求的构建？作者回复: 这是一个解耦问题，一定要保证独立组件能够独立构建，甚至部署。微服务流行也是这个道理
- 2018-09-21代码上线和业务上线的解耦分离，能举个栗子吗，呵呵😄
作者回复: 比如利用功能开关，功能代码上线，但开关不开，功能暂不生效
2018-07-18可以认为 持续交付=DevOps？
2018-07-05能简单介绍下你们的持续交付演进路线吗，首先做了自动部署，后面紧接着做了哪些？作者回复: 部署之后，就可以利用优势解决环境问题；而环境管理会对编译打包有一定要求，比如配置等；如果是小团队的话，也可以在初期就订立分支规范；如果分支规范已经比较分散，则最后处理