26 | 持续交付：如何做到随时发布新版本到生产环境？
该思维导图由 AI 生成，仅供参考
集成、部署和交付的发展史
集成的发展演变
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
持续交付在软件开发中扮演着重要角色，通过自动化流程实现代码提交后的自动编译、测试和部署，使得新版本能随时发布到生产环境。持续交付包括持续集成、持续交付和持续部署三个概念，经历了从痛苦的手动集成到自动化持续集成的转变，以及从手动部署到持续交付和持续部署的演变。持续集成通过频繁集成和自动化测试保证代码稳定性，而持续交付和持续部署进一步简化了部署和发布流程，减少了人为操作和配置错误的可能性。然而，持续部署仍面临自动化测试覆盖率和稳定性的挑战，需要引入新的自动化测试代码和功能开关来确保稳定性。 文章还介绍了如何搭建持续交付环境，包括准备工作、选择合适的持续集成工具和实施步骤。持续集成工具有多种选择，如Jenkins、Go CD、Travis CI等，每种工具都有其特点和适用场景。在实施过程中，需要做好准备工作，选择合适的工具，并按照工具的说明进行搭建。 总的来说，持续交付能够提高开发效率和代码质量，但在实施过程中也会面临一些挑战。对于读者来说，了解持续交付的概念和实施步骤，以及选择合适的工具是非常有帮助的。文章还推荐了一本系统讲述持续交付的书籍，可以进一步深入了解这一领域的知识。
《软件工程之美》，新⼈⾸单¥59
全部留言(13)
- 最新
- 精选
微思老师，现在还有一种说法：提倡基于主分支开发，效率更高；而不是您提到的每人基于自己的分支开发完再合并回主分支。您怎么看待这个问题？作者回复: 我认为对于软件工程来说，很多问题，并不是只有唯一解，即使是最佳实践，也得看适用的场景和团队。 无论是基于主干还是分支开发，有两点需要注意的： 1. 就是一定要有一个稳定的分支，可以随时发布的那种，至于是叫master还是叫release并不重要。 2. 合并之前要有代码审查和自动化测试（配合CI）。 上面两点才是核心。
2019-04-2715
纯洁的憎恶持续集成，分支程序自动合并到主干程序。 持续交付，在持续集成的基础上自动部署测试环境。 持续发布，在持续交付的基础上自动部署生产环境。作者回复: 💯
2019-04-298- alva_xucicd中有一个基础能力就是自动化测试。老师能否详细介绍一下自动化测试的不同场景、采用的工具流程、测试条件的准备，输入输出等？谢谢
作者回复: 会的，第29篇就是自动化测试。 另外你说的场景是不是指的单元测试、集成测试、端对端测试这样的场景？
2019-04-296 
会飞的水箭龟我是从事自动化设备的软件开发的的，我一直很困惑的是自动化设备的软件自动化测试应该如何做？主要有两个困惑：第一，像互联网开发的软件，很多输入通过写测试用例，直接让自动测试工具去测，但自动化设备却不一样，很多时候需要传感器的数据（当然可以模拟），而传感器检测到的数据也是变化很大的（如摄像头），无法一一列出测试用例；第二，测试结果一般是直接看设备的运行情况而不是看是否自动测试通过，无法量化结果。 对于上述问题，宝玉老师有没有什么好的建议？作者回复: 既然你能模拟数据，那么就可以自动化测试了，参考《29 | 自动化测试：如何把Bug杀死在摇篮里？》中的内容。 一个完整的自动化测试要包括三个部分的测试：验证功能是不是正确、覆盖边界条件、异常和错误处理。 你不需要覆盖所有的测试，你只要覆盖上面三部分就可以。 剩下的你就是要解决如何校验测试结果的问题了。我对硬件所知有限，不知道是否有方法可以做到。你也可以考虑是否有间接的方式，比如说一个测试用例完成，通过软件触发拍一张照片，然后你集中确认这些照片，那么还是可以减少很多劳动。
2019-10-184
小老鼠最新统计，中国软件公司2019年上半年自动化测试真正搭起来仅占5％，这种情况下如何普级CICD？作者回复: 先不用管其他人其他公司如何，先从自己做起，从手头的项目做起🤝
2019-09-214
Charles从老师前面的文章以及这篇文章深刻认识到单元测试和自动化测试是我们项目的薄弱点 其它的持续集成git和git flow、根据环境自动打包、生产环境也自动化部署这个由于第三方服务的便利性已经在实践了，效果很好出错率降低很多，而且一旦有问题还能快速会滚作者回复: 👍赞，从工具入手，从持续集成、自动化测试、代码审查这些好的开发实践开始，就能很快起到改进的效果。然后再是优化开发流程，把好的实践工具化流程化。最后再考虑去优化开发模型，去优化开发过程中的各个环节。
2019-04-273
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-292
dancer在微服务架构中，一个服务在测试环境的交付验证，往往还依赖于其他相关服务的新版本，导致新的feature很难独立的交付。请问老师，对于这种情况，有什么好的方法嘛？作者回复: 我觉得对于大部分时候，微服务之间应该是独立的，而不是依赖过于紧密，如果每一个新功能都会这样，那架构设计一定是有问题的，需要重新思考服务划分的合理性。 但你需要有更多上线或者场景我才能针对性提出一些意见。 对于有一些确实需要跨服务合作的大Feature这样也是正常的，就是需要一起协作，实现商量好通信协议，分头开发，再联调。
2019-04-272- calvins开发环境或者测试环境与生产环境隔离，网络做了隔离，生产环境还是做不了持续交付，所以导致了还是需要人工介入。
作者回复: 生产环境要人工介入这个是正常的，但还是要考虑一些可以优化提高的地方，比如说： - 整个部署过程应该尽可能保证自动化，人工只是发动部署和监控部署过程，并不需要太多手工操作 - 做好监控和自动报警，有问题及时回滚（要做到可以回滚） - 测试环境和生产环境应该尽可能一致，在测试环境部署的程序也应该尽可能一致，避免出现同样代码部署在测试环境正常，一部署到生产环境就出问题
2020-01-021 - hua168集成指的就是每个人把自己开发的分支代码，合并到主干上，以便测试打包。 集成包括编译，运行，测试吗？ 持续集成=不断的进行集成操作？
作者回复: 广义的集成是包含代码合并、编译、自动测试还有部署的。 持续集成就是频繁的集成，例如每次提交代码都会集成，或者可以手动触发集成。
2019-04-291
