浅谈持续集成、持续交付、持续部署与DevOps环境

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

整个生命周期（从集成和测试阶段，到交付和部署），这些关联的事务通常被统称为“CI/CD 管道”，由开发、测试、运维团队以敏捷方式协同支持。

首先是瀑布，其次是敏捷，现在是DevOps。这就是现代开发人员开发优质产品的方式。随着DevOps的兴起，出现了持续集成，持续交付（CI / CD）和持续部署的新方法，传统的软件开发和交付方法正在迅速过时。

从历史上看，在敏捷时代，大多数公司会以每月、每季度、每半年甚至每年的发行版来部署/销售软件。但是，现在是DevOps时代，每周、每天甚至一天多次都是标准。

当SaaS接管世界时，尤其如此，您可以在不强迫客户下载新组件的情况下，轻松地动态更新应用程序。很多时候，他们甚至都不会意识到事情正在发生变化。

持续集成（CI）

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

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

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

持续集成的重点是将各个开发人员的工作产品融合到一个存储库中。通常，此操作每天要进行多次，其主要目的是为了及早发现集成错误，最终将导致更紧密的内聚和更多的开发协作。

连续输送的目的是使展开或释放过程中固有的摩擦点最小化。

通常，实现涉及自动化构建部署的每个步骤，以便可以随时随地（理想情况下）完成安全的代码发布。

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

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

开发人员不会在每个周期的末尾单独构建功能并提交每个功能，而是会努力在任何一天多次向存储库贡献软件工作产品。

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

在实践中，开发人员通常会在集成时发现新代码与现有代码之间的边界冲突。如果尽早且经常进行，则期望这样的冲突解决方案将更容易执行且成本更低。

当然，需要权衡取舍。此过程更改不提供任何其他质量保证。

许多组织发现这种集成变得更加昂贵，因为它们依靠手动过程来确保新代码不会引入新的错误，也不会破坏现有的代码。

为了减少集成任务中的摩擦，连续集成依赖于测试套件和自动测试执行。

持续交付（CD）

这里借用阮一峰老师的说法，持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段，持续交付可以看作持续集成的下一步。

它强调的是，不管怎么更新，软件是随时随地可以交付的。注意，持续交付在自动化测试和集成结束后，不一定会自动部署。如果有自动部署，则是持续部署的概念了。

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

比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。

持续部署（CD）

持续部署（Continuous Deployment）是指当交付的代码通过评审之后，自动部署到生产环境中。持续部署是持续交付的最高阶段。这意味着，所有通过了一系列的自动化测试的改动都将自动部署到生产环境。它也可以被称为“Continuous Release”。

持续部署扩展了持续交付，因此，如果软件构建通过所有测试，则将自动部署。在这样的过程中，不需要人来决定何时以及什么生产。CI/CD系统的最后一步将自动部署成功退出交付管道的所有构建组件/软件包。

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

结语

持续集成、持续交付、持续部署相辅相成，提供了一个良好的DevOps环境，对于整个团队来说，收益与挑战并行。从软件开发发展的趋势来看，频繁部署、快速交付以及开发测试流程的自动化将成为未来软件工程的重要组成部分。浅谈持续集成、持续交付、持续部署与DevOps环境。