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

持续集成CI（Continuous Integration）：持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽快地发现集成错误。

集成问题会导致大量的返工，包括不得不通过手动合并解决变更冲突，以及多名开发人员共同解决导致自动化测试或手动测试失败的合并问题。因为在传统的开发模式里，代码集成工作通常发生在项目末期，所以在集成工作消耗过多时间时，我们不得不为了按时发布而偷工减料。这会导致另一个恶性循环：既然合并代码如此痛苦，那么大家就索性减少合并次数，而这会使未来的合并工作更加令人痛苦。

持续集成旨在通过将合并代码融入日常工作来解决这个问题。以下图说明持续集成的流程：

CI流程图（来源：mindtheproduct）

开发人员通将代码变更提交到版本控制仓库，触发CI系统，CI服务器立即对代码进行构建、单元测试，输出结果，从而可以确定新代码是否可以和原有代码正确的集成在一起。

持续交付（Continuous Delivery）：持续交付是指所有开发人员都在主干上进行小批量工作，或者在短时间存在的特性分支上工作，并且定期像主干合并，同时始终让主干保持可发布状态，并能做到在正常的工作时间段里按需进行一键式发布。

开发人员在引入任何回归错误时（包括缺陷、性能问题、安全问题、可用性问题等），都能快速得到反馈。一旦发现这类问题，就立即加以解决，从而保证主干始终处于可部署状态。

以下图说明持续交付流程图：

持续交付流程图（来源：mindtheproduct）

持续交付在持续集成的基础上，自动将代码在类生产环境中进行测试，也就是说项目开发人员在提交代码后，在通过集成、构建、单元测试后，还会进行自动化的类生产环境测试，以确保当代码部署到生产环境后可以正常工作。至此，我们的代码就随时处于可部署状态。

持续部署（Continuous Deployment ）：在持续交付的基础上，由开发或运维人员自助式地定期像生产环境部署优质的构建版本，这通常意味着每人每天至少做一次生产环境部署，甚至每当开发人员提交代码变更时，就触发一次自动化部署。

以下图说明持续部署流程图：

持续部署流程图（来源：mindtheproduct）

通过将代码部署过程自动化，从而实现从开发人员从提交代码到编译、测试、部署的全流程不需要人工的干预，加快代码提交到功能上线的速度。从而使开发人员快速看到客户对新特性的满意度，并且能够快速修复故障而不必等运维人员提交故障单。

通常自动化部署必须具备以下条件：

－    保证在持续集成阶段构建的软件包可以部署到生产环境；

－    使生产环境的就绪情况一目了然；

－    为能在生产环境中部署的任何代码，建立一键式和自助式的发布机制； 

－    自动记录审计和合规管理所需的相关内容，包括在哪台机器上运行了命令，运行了什么命令，是谁授权的，以及结果如何；

－    通过冒烟测试验证系统正常工作，并且数据库连接字符串等配置正确；

－    为开发人员快速提供反馈，使他们能够尽快了解部署结果（例如部署是否成功，应用是否能在生产环境正常运行等等）。

总结：从上述定义可知，持续集成是持续交付的前提条件，而持续交付是持续部署的前提条件。通过将集成和部署融入日常工作，能够大大缩短集成时间，降低集成的复杂度，并把部署时间从几个月缩短到几分钟，使我们能够快速地向客户交付价值，同时避免意外事故和服务中断。