浅谈持续集成(CI)、持续交付(CD)、持续部署

浅谈持续集成(CI)、持续交付(CD)、持续部署(CD)

　　CI/CD是实现敏捷和Devops理念的一种方法，具体而言，CI/CD 可让持续自动化和持续监控贯穿于应用的

整个生命周期（从集成和测试阶段，到交付和部署）。

这些关联的事务通常被统称为“CI/CD 管道”，由开发、

测试、运维团队以敏捷方式协同支持。

　　首先是瀑布，其次是敏捷，现在是DevOps。

这就是现代开发人员开发优质产品的方式。

随着DevOps的兴

起，出现了持续集成，持续交付（CI / CD）和持续部署的新方法。

传统的软件开发和交付方法正在迅速过时。

从历史上看，在敏捷时代，大多数公司会以每月，每季度，每半年甚至每年的发行版来部署/销售软件（还记得

那些日子吗？）。

但是，现在在DevOps时代，每周，每天甚至一天多次都是标准。

当SaaS接管世界时，尤其

如此，您可以在不强迫客户下载新组件的情况下，轻松地动态更新应用程序。

很多时候，他们甚至都不会意识

到事情正在发生变化。

持续集成（Continuous Integration）

大师 Martin Fowler 对持续集成是这样定义的：持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，
通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。

每次集成都通过自动化的构建（包括编译，发布，
自动化测试)来验证，从而尽快地发现集成错误。

许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发
内聚的软件。

　　持续集成的重点是将各个开发人员的工作产品融合到一个存储库中。

通常，此 *** 作每天要进行多次，其主

要目的是为了及早发现集成错误，最终将导致更紧密的内聚和更多的开发协作。

连续输送的目的是使展开或释

放过程中固有的摩擦点最小化。

通常，实现涉及自动化构建部署的每个步骤，以便可以随时随地（理想情况下）

完成安全的代码发布。

 连续部署是一种更高的自动化程度，其中，只要对代码进行了重大更改，都会自动进行

构建/部署。

　　通过持续集成，开发人员经常将其代码集成到通用存储库的主分支中。

开发人员不会在每个周期的末尾单

独构建功能并提交每个功能，而是会努力在任何一天多次向存储库贡献软件工作产品。

　　这里的主要想法是通过让开发人员更快，更频繁地进行集成来降低集成成本。

在实践中，开发人员通常会

在集成时发现新代码与现有代码之间的边界冲突。

如果尽早且经常进行，则期望这样的冲突解决方案将更容易

执行且成本更低。

　　当然，需要权衡取舍。

此过程更改不提供任何其他质量保证。

许多组织发现这种集成变得更加昂贵，因为

它们依靠手动过程来确保新代码不会引入新的错误，也不会破坏现有的代码。

为了减少集成任务中的摩擦，连

续集成依赖于测试套件和自动测试执行。

持续交付（Continuous Delivery）

　　这里借用阮一峰老师的说法，持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付

给质量团队或者用户，以供评审。

如果评审通过，代码就进入生产阶段。

持续交付可以看作持续集成的下一步。

它强调的是，不管怎么更新，软件是随时随地可以交付的。

注意，持续交付在自动化测试和集成结束后，不一

定会自动部署。

如果有自动部署，则是持续部署的概念了。

　　持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」

（production-like environments）中。

比如，我们完成单元测试后，可以把代码部署到连接数据库

的 Staging 环境中更多的测试。

如果代码没有问题，可以继续手动部署到生产环境中。

持续部署（Continuous Deployment）

　　持续部署是指当交付的代码通过评审之后，自动部署到生产环境中。

持续部署是持续交付的最高阶

段。

这意味着，所有通过了一系列的自动化测试的改动都将自动部署到生产环境。

它也可以被称为“Continuous Release”。

　　持续部署扩展了持续交付，因此，如果软件构建通过所有测试，则将自动部署。

在这样的过程中，

不需要人来决定何时以及什么生产。

CI/CD系统的最后一步将自动部署成功退出交付管道的所有构建组

件/软件包。

可以将此类自动部署配置为快速向客户分发组件，功能和修补程序，并准确地提供当前生

产中的内容。

结语

　　持续集成、持续交付、持续部署相辅相成，提供了一个良好的DevOps环境，对于整个团队来说，

收益与挑战并行。

从软件开发发展的趋势来看，频繁部署、快速交付以及开发测试流程的自动化将成

为未来软件工程的重要组成部分。