持续集成无法消除bug，但却能大降低修复bug
发表时间：2023-09-07 20:00:47
文章来源：炫佑科技
浏览次数：183
菏泽炫佑科技
持续集成无法消除bug，但却能大降低修复bug
1.持续集成持续集成
CI（）：指持续集成，对于开发人员来说是一个自动化的过程。
在持续集成环境中，开发人员会频繁地将代码提交到主干（重复上述集成工作）。 开发人员提交新代码后，会立即自动构建并执行单元测试，因为这些新提交需要通过编译和自动化测试流程进行验证，然后才能*终合并到主线中。 这是基于在之前的持续集成过程中，我们非常重视自动化测试和验证的结果，以保证合并主线后所有提交的质量持续集成无法消除bug，但却能大降低修复bug，并对可能出现的问题进行预警。 因此，通过持续集成，开发者只需要提交代码就可以得到这次集成的结果。 根据结果可以判断新代码与原代码是否能够正确集成。
持续集成是一种软件开发实践。 团队开发成员经常向代码仓库提交代码。 通常，每个成员每天至少集成一次，这意味着每天可能会有多次集成，并且每次集成都通过自动化构建（包括编译、发布、自动化测试）来验证，以便尽早发现集成错误以便能够尽快解决问题。 持续集成是一种将集成移至开发周期早期的实践，允许更频繁地迭代地构建、测试和集成代码。 持续集成虽然不能消除bug，但可以大大降低修复bug的难度和时间。
2.持续交付CD
CD ( )：指持续交付和/或持续部署，这些相关概念有时可以互换使用。
持续交付是持续集成的延伸，自动将代码部署到预生产环境，以确保新的变更以可持续的方式快速发布给客户。 持续交付是指发布应用程序的过程，确保尽快交付。 这意味着除了自动化测试之外，还需要自动化的发布流程，只需一键即可随时随地部署和启动应用程序。
通过持续交付自动化软件开发，其软件交付过程进一步自动化，以便随时轻松部署到生产环境中。 CD 主要依赖于部署管道，团队通过该管道自动化测试和部署过程。 通过持续交付，你可以决定每天发布、每周发布、或者每两周发布一次，可以根据自己的业务来设置。
3.持续部署CD
持续部署扩展了持续交付，以便软件在通过所有测试时构建并自动部署。
在各个环境中测试过的应用程序会自动部署到生产环境中。 其实各个环境的发布流程都是一样的。 应用发布到生产环境后，需要对应用进行健康检查和应用日志管理。 在这样的过程中，不需要人类来决定何时以及如何投入生产。 CI/CD 系统的*后一步是在构建的组件/包退出管道时自动部署它们，并且可以将这种自动化部署配置为快速向客户分发组件、功能模块或修复程序，并准确说明当前交付的内容。
4. CI/CD开发流程
开发流程：编码->构建->集成->测试->交付->部署
