CICD持续集成/持续部署

什么是CICD

• 一、简介
• 二、持续集成（CI）
• 三、持续交付（CD）
• 四、持续部署（CD）
• 五、下一步是什么？

一、简介

CI / CD的采用改变了开发人员和测试人员如何发布软件。

最初是瀑布模型，后来是敏捷开发，现在是DevOps，这是现代开发人员构建出色的产品的技术路线。随着DevOps的兴起，出现了持续集成（Continuous Integration）、持续交付（Continuous Delivery） 、持续部署（Continuous Deployment） 的新方法。传统的软件开发和交付方法正在迅速变得过时。从历史上看，在敏捷时代，大多数公司会每月，每季度，每两年甚至每年发布部署/发布软件。然而，现在，在DevOps时代，每周，每天，甚至每天多次是常态。当SaaS正在占领世界时，尤其如此，您可以轻松地动态更新应用程序，而无需强迫客户下载新组件。很多时候，他们甚至都不会意识到正在发生变化。开发团队通过软件交付流水线（Pipeline）实现自动化，以缩短交付周期，大多数团队都有自动化流程来检查代码并部署到新环境。今天，我们将介绍什么是CI / CD / CD，以及现代软件公司如何使用工具将部署代码的流程自动化。
持续集成的重点是将各个开发人员的工作集合到一个代码仓库中。通常，每天都要进行几次，主要目的是尽早发现集成错误，使团队更加紧密结合，更好地协作。
持续交付的目的是最小化部署或释放过程中固有的摩擦。它的实现通常能够将构建部署的每个步骤自动化，以便任何时刻能够安全地完成代码发布（理想情况下）。
持续部署是一种更高程度的自动化，无论何时对代码进行重大更改，都会自动进行构建/部署。
这些阶段中的每一个都是交付管道的一部分 。在Humble和Farley的书《持续交付：可靠的软件版本中，通过构建，测试和部署自动化》，解释“对软件的每次更改，都会在发布过程中经历一个复杂的过程。该过程涉及构建软件，然后通过多个测试和部署阶段进行这些构建。反过来，这需要许多人之间的合作，也许需要几个团队之间的合作。部署管道对此过程进行建模，并且它在持续集成和发布管理工具中的实现，使您能够在从版本控制转移到各种测试和部署，以向用户发布时查看和控制每个更改的进度。”

软件交付流水线

二、持续集成（CI）

通过持续集成，开发人员能够频繁将其代码集成到公共代码仓库的主分支中。开开发人员能够在任何时候多次向仓库提交作品，而不是独立地开发每个功能模块并在开发周期结束时一一提交。
这里的一个重要想法是让开发人员更快，更频繁地做到这一点，从而降低集成成本。实际情况中，开发人员在集成时经常会发现新代码和已有代码存在冲突。如果集成较早并更加频繁，那么冲突将更容易解决且执行成本更低。当然，还有一些权衡。此流程变更不提供任何额外的质量保证。实际上，许多组织发现这种集成变得更加昂贵，因为它们依赖于手动过程来确保新代码不会引入新的错误，并且不会破坏现有代码。为了减少集成任务期间的摩擦，持续集成依赖于测试套件和自动化测试执行。然而，要认识到自动化测试和持续测试是完全不同的这一点很重要，我们会在文章结尾处详细说明。
CI 的目标是将集成简化成一个简单、易于重复的日常开发任务，这将有助于降低总体构建成本，并在周期的早期发现缺陷。要想有效地使用 CI 必须转变开发团队的习惯，要鼓励频繁迭代构建，并且在发现 bug 的早期积极解决。

三、持续交付（CD）

实际上是 CI 的扩展，其中软件交付流程进一步自动化，以便随时轻松地部署到生成环境中。CD 集中依赖于部署流水线，团队通过流水线自动化测试和部署过程。此流水线是一个自动化系统，可以针对构建执行一组渐进的测试套件。CD 具有高度的自动化，并且在一些云计算环境中也易于配置。在流水线的每个阶段，如果构建无法通过关键测试会向团队发出警报。否则，将继续进入下一个测试，并在连续通过测试后自动进入下一个阶段。流水线的最后一个部分会将构建部署到和生产环境等效的环境中。这是一个整体的过程，因为构建、部署和环境都是一起执行和测试的，它能让构建在实际的生产环境可部署和可验证。
AWS上提供了现代CI / CD管道的可靠展示。亚马逊是云计算提供商之一，提供令人印象深刻的CI / CD 管道环境，并提供一个演练过程，您可以从其中选择众多开发资源，并将它们链接在一个易于配置且易于监控的管道中。

许多人认为持续交付的吸引力主要在于，它自动化了从提交代码到仓库，再到测试和发布产品过程的所有步骤。这是构建和测试过程细致的自动化，但是如何发布以及发布什么仍然是需要人工操作，持续部署可以改变这一点。

四、持续部署（CD）

持续部署扩展了持续交付，以便软件构建，在通过所有测试时自动部署。在这样的流程中，不需要人为决定何时及如何投入生产环境。CI/CD 系统的最后一步将在构建后的组件/包退出流水线时自动部署。此类自动部署可以配置为快速向客户分发组件、功能模块或修复补丁，并准确说明当前提供的内容。
采用持续部署的组织可以将新功能快速传递给用户，得到用户对于新版本的快速反馈，并且可以迅速处理任何明显的缺陷。用户对无用或者误解需求的功能的快速反馈有助于团队规划投入，避免将精力集中于不容易产生回报的地方。随着 DevOps 的发展，新的用来实现 CI/CD 流水线的自动化工具也在不断涌现。这些工具通常能与各种开发工具配合，包括像 GitHub 这样的代码仓库和 Jira 这样的 bug 跟踪工具。此外，随着 SaaS 这种交付方式变得更受欢迎，许多工具都可以在现代开发人员运行应用程序的云环境中运行，例如 GCP 和 AWS。最受欢迎的自动化工具是 Jenkins（以前的 Hudson），这是一个由数百名贡献者和商业公司 Cloudbees 支持的开源项目。Cloudbees 甚至聘请了 Jenkins 的创始人，并提供了一些 Jenkins 培训项目和附加组件。除了开源项目之外，还有一些更现代化的商业产品例如 CircleCI，Codeship 和 Shippable。这些产品各有优缺点，我鼓励开发人员在开发流程中一一尝试它们，以了解它们在您的环境中的工作方式，以及它们如何与您的工具、云平台、容器系统等协作。

五、下一步是什么？

一旦部署了现代化的 CI/CD 流水线，您可能会意识到开发人员工作流程中的一些工具和流程也需要进行现代化改造。测试是一个要着重关注的领域，如果您的部署频率是每天或者一天多次，您的每次测试可能需要数小时甚至一晚上才能完成。mabl 正在使用机器学习解决这个问题。