持续集成持续交付是一种 DevOps 软件开发实践。采用持续集成时，开发人员会定期将代码变更合并到一个中央存储库中，之后系统会自动运行构建和测试操作。持续集成通常是指软件发布流程的构建或集成阶段，需要用到自动化组件（例如 CI 或构建服务）和文化组件（例如学习频繁地集成）。持续集成的主要目标是更快发现并解决缺陷，提高软件质量，并减少验证和发布新软件更新所需的时间。

通过持续交付，系统可以自动为将代码更改发布到生产环境做好准备。​现代应用程序开发的支柱，持续交付通过在构建阶段后将所有代码变更部署到测试环境和/或生产环境中，实现对持续集成的扩展。在正确实施时，开发人员将始终拥有已通过标准化测试流程的部署就绪构建构件​。

采用持续交付时，开发人员可以自动执行单元测试以外的测试，这样他们就可以在部署到客户环境前跨多个维度对应用程序更新进行验证。这些测试可能包括 UI 测试、负载测试、集成测试、API 可靠性测试等。这有助于开发人员更全面地验证更新并抢先发现其中的问题。借助云，开发人员可轻松高效地自动创建和复制多个用于测试的环境，而这一点以前在本地很难实现。

为什么需要CICD？

过去，一个团队的开发人员可能会孤立地工作很长一段时间，只有在他们的工作完成后，才会将他们的更改合并到主分支中。这使得合并代码更改变得困难而耗时，而且还会导致错误积累很长时间而得不到纠正。这些因素导致更加难以迅速向客户交付更新。

持续交付与持续部署

采用持续交付时，系统会构建并测试每一个代码变更，然后将其推送到非生产测试环境或临时环境中。生产部署前可能存在多个并行测试阶段。持续交付与持续部署之间的区别在于，需要手动批准才能更新到生产环境。对于持续部署，生产会在没有明确批准的情况下自动发生。

持续交付可实现整个软件发布流程的自动化。提交的每一个修订都会触发一个自动化流程，即构建、测试并提供更新。部署到实际生产环境的最终决定由开发人员触发。

持续交付不是持续部署

关于持续交付的一个误解是，提交的每一个更改都在通过自动化测试后立即应用到生产中。然而，持续交付的关键不是立即将每一个变更应用到生产中，而是确保每一个变更都准备好投入生产。在将更改部署到生产环境之前，可以实现决策过程，以确保生产部署经过授权和审核。这个决定可以由一个人做出，然后由工具执行。

使用持续交付，上线的决定将成为一个业务决策，而不是技术决策。每次提交时都会进行技术验证。将变更发布到生产环境并不是一个破坏性事件。部署不需要技术团队停止处理下一组更改，也不需要项目计划、移交文档或维护窗口。部署成为一个可重复的过程，已在测试环境中多次执行和验证。

持续集成持续交付的优势

• 自动化软件发布流程

持续交付让您的团队能够自动构建、测试并准备代码变更，以便发布到生产环境中，从而使您的软件交付更加高效、快速。提高开发人员的工作效率

• 提高开发人员的工作效率

持续集成可将开发人员从手动任务中解放出来，并且鼓励有助于减少发布到客户环境中的错误和缺陷数量的行为，从而提高团队的工作效率。

• 更快发现并解决缺陷

通过更频繁的测试，您的团队可以在缺陷稍后变成大问题前发现并解决这些缺陷。

• 更快交付更新

持续集成有助于您的团队更快、更频繁地向客户交付更新。