什么是持续集成和持续交付/部署？

本节讨论持续集成和持续交付的实践，并解释持续交付和持续部署之间的区别。

持续集成

持续集成 (CI) 是一种软件开发实践，采用持续集成时，开发人员会定期将他们的代码更改合并到一个中央存储库中，之后系统会自动运行构建和测试操作。CI 通常涉及软件发布流程的构建或集成阶段，并同时需要自动化部分（例如，CI 或构建服务）和文化部分（例如，频繁集成方面的知识）。CI 的主要目标是更快地发现并解决错误，提高软件质量，并缩短验证和发布新软件更新所需的时间。

持续集成侧重于要集成的较小提交和较小的代码更改。开发人员定期提交代码，每天至少提交一次。开发人员从代码存储库中提取代码，以确保在推送到编译服务器之前合并本地主机上的代码。在此阶段，编译服务器将运行各种测试，并接受或拒绝代码提交。

实施 CI 的基本挑战包括更频繁地提交到公共代码库、维护单一源代码存储库、自动执行构建以及自动执行测试。其他挑战包括：在与生产环境类似的环境中进行测试，向团队提供过程的可见性，以及允许开发人员轻松获得应用程序的任何版本。

持续交付和部署

持续交付 (CD) 是一种软件开发实践，通过持续交付，系统可以自动构建和测试代码更改，并为生产发布做好准备。它可以在持续集成的基础之上进行扩展，也即，在完成构建阶段后，将所有代码更改都部署到测试环境和/或生产环境中。持续交付可以通过工作流程实现完全自动化，也可以在关键点通过手动步骤实现部分自动化。当持续交付得以正确实施时，开发人员将始终能够获得一个已通过标准化测试流程的部署就绪型构建构件。

采用持续部署时，系统会在未经开发人员明确批准的情况下自动将修订部署到生产环境中，从而实现整个软件发布流程的自动化。这反过来又允许在产品生命周期的早期建立持续的客户反馈循环。

持续交付不是持续部署

关于持续交付的一个误解是，它意味着提交的每一项更改都会在通过自动化测试后立即应用于生产。但是，持续交付的目的不是立即将所有更改应用到生产中，而是要确保每个更改都已准备好投入生产。

在将更改部署到生产环境之前，您可以实施决策流程，以确保对生产部署进行授权和审计。这个决定可以由人做出，然后由工具执行。

使用持续交付，投入生产的决定变成了业务决策，而不是技术决策。每次提交时都会进行技术验证。

向生产环境推出更改不是破坏性事件。部署不要求技术团队停止处理下一组更改，也不需要项目计划、移交文档或维护窗口。部署成为一个可重复的过程，而这一过程已经在测试环境中得以多次执行和验证。