持续集成、持续交付和持续部署

引言

在遵循敏捷方法论等软件模型时，我们通常会遇到持续集成、持续交付和持续部署这些术语。 这些术语常常令人困惑，并且相互关联。 让我们找出它们之间的区别，并尝试理解它们在软件开发中的实际含义，以及它们如何协同工作，从而形成一个让管理者、开发人员和客户都乐于遵循的流程。

持续集成

持续集成是指不断地将你的代码或开发工作合并到主分支（Master 或 Main）中，这样你就可以在处理其他事情的同时，对已提交/合并的代码进行测试。 其基本逻辑是在代码提交时尽早地进行测试，并尽早发现或捕获错误，以便在更改推送到生产环境之前修复它们。 大部分工作都是使用构建服务器自动化的，构建服务器会执行这些测试，并且开发人员可以同时处理他们的任务。

持续交付

持续交付是一个持续将代码交付到环境的过程，当开发人员认为代码可以发布时，就会进行交付。 这个环境可以是暂存环境、QA 环境或生产环境。 其基本思想是审查或检查已发布的代码，以便尽早发现和修复任何问题。 这类似于持续集成，但在这里我们可以测试业务逻辑。 你还可以对已交付的代码进行代码审查，获取反馈，并根据反馈进行代码修正。 在这个过程中，交付的代码会连同所需的配置和设置一起发布，以确保交付的代码在相同的环境中运行。 持续交付的基础是小批量的代码发布到下一阶段，以便识别已交付代码中的任何错误/问题。

持续部署

持续部署是指在代码准备就绪后立即将其部署或发布到生产环境的过程。 在合并到主分支之前执行的所有测试都将在与生产环境相似的生产环境（包括所有配置设置）中进行，以避免进一步的问题。 这种部署到生产环境是通过自动化过程完成的。 这个自动化过程可以由任何人通过几分钟（例如，通过几次点击）来执行。 持续部署过程需要持续集成和持续交付，否则你可能会在生产环境中遇到一些错误。 在这个完整的过程中，你应该使用构建服务器自动化你的持续集成，并自动化到暂存环境的持续交付，以及自动化到生产环境的部署过程。

因此，持续集成、持续交付和持续部署协同工作，以尽可能减少错误地将代码发布到生产环境，这意味着它会关注你的产品的质量。 开发人员将代码签入到开发分支，构建服务器会获取更改，并执行单元测试。 如果单元测试通过，则会将代码合并到暂存环境。 如果暂存环境的部署成功，则 QA 会测试该环境，如果测试通过，则将其移动到生产环境。 此过程可能会根据项目需求而有所不同。

持续部署主要依赖于经过持续测试并部署和发布到生产环境的小幅更改，在经过先前环境的测试之后。