26 | 持续交付：如何做到随时发布新版本到生产环境？
集成、部署和交付的发展史
集成的发展演变
请订阅文章所属专栏。
精选留言(10)
W.T老师，现在还有一种说法：提倡基于主分支开发，效率更高；而不是您提到的每人基于自己的分支开发完再合并回主分支。您怎么看待这个问题？作者回复: 我认为对于软件工程来说，很多问题，并不是只有唯一解，即使是最佳实践，也得看适用的场景和团队。
无论是基于主干还是分支开发，有两点需要注意的：
1. 就是一定要有一个稳定的分支，可以随时发布的那种，至于是叫master还是叫release并不重要。
2. 合并之前要有代码审查和自动化测试（配合CI）。
上面两点才是核心。2019-04-27 5
纯洁的憎恶持续集成，分支程序自动合并到主干程序。
持续交付，在持续集成的基础上自动部署测试环境。
持续发布，在持续交付的基础上自动部署生产环境。作者回复: 💯
2019-04-29 3- alva_xucicd中有一个基础能力就是自动化测试。老师能否详细介绍一下自动化测试的不同场景、采用的工具流程、测试条件的准备，输入输出等？谢谢
作者回复: 会的，第29篇就是自动化测试。
另外你说的场景是不是指的单元测试、集成测试、端对端测试这样的场景？2019-04-29 3 
Charles从老师前面的文章以及这篇文章深刻认识到单元测试和自动化测试是我们项目的薄弱点
其它的持续集成git和git flow、根据环境自动打包、生产环境也自动化部署这个由于第三方服务的便利性已经在实践了，效果很好出错率降低很多，而且一旦有问题还能快速会滚作者回复: 👍赞，从工具入手，从持续集成、自动化测试、代码审查这些好的开发实践开始，就能很快起到改进的效果。然后再是优化开发流程，把好的实践工具化流程化。最后再考虑去优化开发模型，去优化开发过程中的各个环节。
2019-04-27 2- 会飞的水箭龟我是从事自动化设备的软件开发的的，我一直很困惑的是自动化设备的软件自动化测试应该如何做？主要有两个困惑：第一，像互联网开发的软件，很多输入通过写测试用例，直接让自动测试工具去测，但自动化设备却不一样，很多时候需要传感器的数据（当然可以模拟），而传感器检测到的数据也是变化很大的（如摄像头），无法一一列出测试用例；第二，测试结果一般是直接看设备的运行情况而不是看是否自动测试通过，无法量化结果。
对于上述问题，宝玉老师有没有什么好的建议？作者回复: 既然你能模拟数据，那么就可以自动化测试了，参考《29 | 自动化测试：如何把Bug杀死在摇篮里？》中的内容。
一个完整的自动化测试要包括三个部分的测试：验证功能是不是正确、覆盖边界条件、异常和错误处理。
你不需要覆盖所有的测试，你只要覆盖上面三部分就可以。
剩下的你就是要解决如何校验测试结果的问题了。我对硬件所知有限，不知道是否有方法可以做到。你也可以考虑是否有间接的方式，比如说一个测试用例完成，通过软件触发拍一张照片，然后你集中确认这些照片，那么还是可以减少很多劳动。2019-10-18 1 
小老鼠最新统计，中国软件公司2019年上半年自动化测试真正搭起来仅占5％，这种情况下如何普级CICD？作者回复: 先不用管其他人其他公司如何，先从自己做起，从手头的项目做起🤝
2019-09-21 1
hua168如果一个项目有5个开发做，持续集成怎么保证不乱？
比如开发A刚刚修复的bug1，开发B把自己修复的bug2上传，之前的代码bug1没修复
怎么搞？
如果采用分支怎么合并？如果是直接更新master分支，那A不是白搞了？
难道这样一个QQ群，开发A更新的代码，然后到群里说一下他更新的代码，叫其他开发git一个新的版本，然后基于这个版本进行修改bug？作者回复: 要注意是“合并”而不是“覆盖”
比如说bug1涉及file1和file3的修改，那么开发A合并的时候只合并file1和file3。
等到开发B修复了bug2，修改了file1和file2，file2直接合并，file1需要手动去修复合并冲突才能合并。
每个人开发之前，都会从master获取最新版本，合并的时候，如果出现冲突，要先解决冲突才能合并进去。
这些其实你应该自己去动手试试，会体会更深刻。2019-04-29 1- hua168集成指的就是每个人把自己开发的分支代码，合并到主干上，以便测试打包。
集成包括编译，运行，测试吗？
持续集成=不断的进行集成操作？作者回复: 广义的集成是包含代码合并、编译、自动测试还有部署的。
持续集成就是频繁的集成，例如每次提交代码都会集成，或者可以手动触发集成。2019-04-29 1 
dancer在微服务架构中，一个服务在测试环境的交付验证，往往还依赖于其他相关服务的新版本，导致新的feature很难独立的交付。请问老师，对于这种情况，有什么好的方法嘛？作者回复: 我觉得对于大部分时候，微服务之间应该是独立的，而不是依赖过于紧密，如果每一个新功能都会这样，那架构设计一定是有问题的，需要重新思考服务划分的合理性。
但你需要有更多上线或者场景我才能针对性提出一些意见。
对于有一些确实需要跨服务合作的大Feature这样也是正常的，就是需要一起协作，实现商量好通信协议，分头开发，再联调。2019-04-27 1- alva_xu是的2019-04-29