当前位置 博文首页 > EdisonYao：浅谈持续集成(CI)、持续交付(CD)、持续部署(CD)
CI/CD是实现敏捷和Devops理念的一种方法，具体而言，CI/CD 可让持续自动化和持续监控贯穿于应用的
整个生命周期（从集成和测试阶段，到交付和部署）。这些关联的事务通常被统称为“CI/CD 管道”，由开发、
测试、运维团队以敏捷方式协同支持。
首先是瀑布，其次是敏捷，现在是DevOps。这就是现代开发人员开发优质产品的方式。随着DevOps的兴
起，出现了持续集成，持续交付（CI / CD）和持续部署的新方法。传统的软件开发和交付方法正在迅速过时。
从历史上看，在敏捷时代，大多数公司会以每月，每季度，每半年甚至每年的发行版来部署/销售软件（还记得
那些日子吗？）。但是，现在在DevOps时代，每周，每天甚至一天多次都是标准。当SaaS接管世界时，尤其
如此，您可以在不强迫客户下载新组件的情况下，轻松地动态更新应用程序。很多时候，他们甚至都不会意识
到事情正在发生变化。
大师 Martin Fowler 对持续集成是这样定义的：持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，
通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，
自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发
内聚的软件。
持续集成的重点是将各个开发人员的工作产品融合到一个存储库中。通常，此操作每天要进行多次，其主
要目的是为了及早发现集成错误，最终将导致更紧密的内聚和更多的开发协作。连续输送的目的是使展开或释
放过程中固有的摩擦点最小化。通常，实现涉及自动化构建部署的每个步骤，以便可以随时随地（理想情况下）
完成安全的代码发布。 连续部署是一种更高的自动化程度，其中，只要对代码进行了重大更改，都会自动进行
构建/部署。
通过持续集成，开发人员经常将其代码集成到通用存储库的主分支中。开发人员不会在每个周期的末尾单
独构建功能并提交每个功能，而是会努力在任何一天多次向存储库贡献软件工作产品。
这里的主要想法是通过让开发人员更快，更频繁地进行集成来降低集成成本。在实践中，开发人员通常会
在集成时发现新代码与现有代码之间的边界冲突。如果尽早且经常进行，则期望这样的冲突解决方案将更容易
执行且成本更低。
当然，需要权衡取舍。此过程更改不提供任何其他质量保证。许多组织发现这种集成变得更加昂贵，因为
它们依靠手动过程来确保新代码不会引入新的错误，也不会破坏现有的代码。为了减少集成任务中的摩擦，连
续集成依赖于测试套件和自动测试执行。
这里借用阮一峰老师的说法，持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付
给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。 持续交付可以看作持续集成的下一步。
它强调的是，不管怎么更新，软件是随时随地可以交付的。注意，持续交付在自动化测试和集成结束后，不一
定会自动部署。如果有自动部署，则是持续部署的概念了。
持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」
（production-like environments）中。比如，我们完成单元测试后，可以把代码部署到连接数据库
的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。
持续部署是指当交付的代码通过评审之后，自动部署到生产环境中。持续部署是持续交付的最高阶
段。这意味着，所有通过了一系列的自动化测试的改动都将自动部署到生产环境。它也可以被称为“Continuous Release”。
持续部署扩展了持续交付，因此，如果软件构建通过所有测试，则将自动部署。在这样的过程中，
不需要人来决定何时以及什么生产。CI/CD系统的最后一步将自动部署成功退出交付管道的所有构建组
件/软件包。可以将此类自动部署配置为快速向客户分发组件，功能和修补程序，并准确地提供当前生
产中的内容。
持续集成、持续交付、持续部署相辅相成，提供了一个良好的DevOps环境，对于整个团队来说，
收益与挑战并行。从软件开发发展的趋势来看，频繁部署、快速交付以及开发测试流程的自动化将成
为未来软件工程的重要组成部分。
