什么是CI / CD（Continuous integration and continuousdelivery）？持续集成和持续交付的说明

 

CI / CD管道是devop团队可以实施的最佳实践之一，可以更频繁，更可靠地交付代码更改。

持续集成（CI）和持续交付（CD）体现了一种文化，一套操作原则和一系列实践，使应用程序开发团队能够更频繁，更可靠地交付代码更改。该实现也称为CI / CD管道。

 

CI / CD是开发团队实施的最佳实践之一。这也是一种敏捷方法论的最佳实践，因为它使软件开发团队能够专注于满足业务需求，代码质量和安全性，因为部署步骤是自动化的。

 

1.1 CI / CD定义

持续集成是一种编码哲学和一系列实践，可推动开发团队实施较小的更改并频繁检入代码以进行版本控制存储库。因为大多数现代应用程序需要在不同的平台和工具上开发代码，所以团队需要一种机制来集成和验证其更改。

CI的技术目标是建立一致，自动化的方式来构建，打包和测试应用程序。有了集成过程中的一致性，团队就更有可能更频繁地提交代码更改，从而带来更好的协作和软件质量。

 

持续交付会在持续集成结束的地方增加收益。 CD可以自动将应用程序交付到选定的基础架构环境。大多数团队都在生产环境以外的其他环境中工作，例如开发和测试环境，并且CD确保有自动方式将代码更改推送到他们。

 

CI / CD工具有助于存储每次交付时都必须打包的特定于环境的参数。然后，CI / CD自动化会对部署应用程序时可能需要重新启动或遵循其他过程的Web服务器，数据库和其他服务执行任何必要的服务调用。

 

持续集成和持续交付需要持续测试，因为目标是向用户交付高质量的应用程序和代码。连续测试通常被实现为一组自动回归，性能以及在CI / CD管道中执行的其他测试。

成熟的CI / CD开发人员可以选择实施连续部署，其中通过CI / CD管道运行应用程序更改，并将传递的构建直接部署到生产环境。进行连续交付的团队选择按每天甚至每小时的时间表部署到生产中，尽管持续交付并非总是适用于每个业务应用程序。

1.2 持续集成如何改善协作和质量

持续集成是一种以过程力学和某种自动化为后盾的发展理念。在实践CI时，开发人员经常将其代码提交到版本控制存储库中，并且大多数团队至少每天至少提交一次代码。其基本原理是，在较小的代码差异上识别缺陷和其他软件质量问题比在较长时期内开发出较大的问题更容易。另外，当开发人员以较短的提交周期进行工作时，多个开发人员不太可能编辑相同的代码并在提交时需要合并。

 

实施持续集成的团队通常从版本控制配置和实践定义开始。即使经常检查代码，但功能和修复都是在较短和较长的时间范围内实现的。练习持续集成的开发团队使用不同的技术来控制准备好生产的功能和代码。

许多团队使用功能标记，这是一种配置机制，可以在运行时打开或关闭功能和代码。仍在开发中的功能部件在代码中用功能部件标志包装，并与master分支一起部署到生产环境，并在准备好使用之前将其关闭。根据最近的一项调查，使用功能标记的团队中有63％的团队表示测试更好，软件质量更高。功能标记工具（例如CloudBees部署，Optimizely部署和LaunchDarkly）与CI / CD工具集成并启用功能级别的配置。

 

管理功能的另一种技术是版本控制分支。选择诸如Gitflow之类的分支策略来定义有关如何将新代码合并到标准分支中以进行开发，测试和生产的协议。为需要较长开发周期的功能分支创建其他功能分支。功能完成后，开发人员可以将功能分支中的更改合并到主要开发分支中。这种方法效果很好，但是如果同时开发许多功能，可能会变得难以管理。

 

然后，通过打包所有软件，数据库和其他组件，使构建过程本身自动化。例如，如果您正在开发Java应用程序，则CI会将所有静态Web服务器文件（如HTML，CSS和JavaScript）与Java应用程序和任何数据库脚本一起打包。

CI不仅打包所有软件和数据库组件，而且自动化还将执行单元测试和其他测试。这项测试可为开发人员提供反馈，说明他们的代码更改没有破坏任何现有的单元测试。

 

大多数CI / CD工具都允许开发人员根据版本控制库中的代码提交或按定义的时间表触发按需启动的构建。团队需要讨论最适合团队规模，预期的每日提交次数以及其他应用程序注意事项的构建计划。确保提交和构建速度最快的最佳实践，否则，可能会妨碍团队尝试快速编码和频繁提交的进度。

 

1.3 连续测试超越了测试自动化

自动化的测试框架可帮助质量保证工程师定义，执行和自动化各种类型的测试，以帮助开发团队了解软件构建是通过还是失败。它们包括在每次冲刺结束时开发的功能测试，并汇总到整个应用程序的回归测试中。然后，这些回归测试会通知团队代码更改是否失败了在覆盖测试的应用程序所有功能区域中开发的一项或多项测试。

 

最佳实践是启用并要求开发人员在其本地环境中运行全部或部分回归测试。此步骤可确保开发人员仅在回归测试通过代码更改后才将代码提交到版本控制。

回归测试仅仅是开始。性能测试，API测试，静态代码分析，安全性测试和其他测试形式也可以实现自动化。关键是能够通过命令行，webhook或Web服务触发这些测试，并且它们以成功或失败状态代码响应。

 

一旦测试自动化，连续测试意味着该自动化已集成到CI / CD管道中。某些单元和功能测试可以集成到CI中，以在集成过程之前或期间标记问题。需要完整交付环境的测试（例如性能和安全性测试）通常集成到CD中，并在将构建交付给目标环境之后执行。

 

1.4 CD管道可自动对多个环境进行更改

持续交付是将应用程序推送到交付环境的自动化。大多数开发团队通常具有一个或多个开发和测试环境，在该环境中会进行应用程序更改以进行测试和审查。诸如Jenkins，CircleCI，AWS CodeBuild，Azure DevOps，Atlassian Bamboo或Travis CI之类的CI / CD工具用于自动执行步骤并提供报告。

典型的CD管道具有构建，测试和部署阶段。更复杂的管道包括以下许多步骤：

 

• 从版本控制中提取代码并执行构建。

• 执行任何必需的基础架构步骤，这些步骤将自动以代码的形式建立或拆除云基础架构。

• 将代码移至目标计算环境。

• 管理环境变量并为目标环境配置它们。

• 将应用程序组件推送到其适当的服务，例如Web服务器，API服务和数据库服务。

• 执行重新启动服务或调用新代码推送所需的服务端点所需的任何步骤。

• 如果测试失败，则执行连续测试和回滚环境。

• 提供日志数据和有关交付状态的警报。

例如，Jenkins用户在Jenkins文件中定义其管道，该文件描述了不同的阶段，例如构建，测试和部署。环境变量，选项，秘密密钥，证书和其他参数在文件中声明，然后分阶段引用。帖子部分处理错误情况和通知。

 

更复杂的CD可能具有其他步骤，例如执行数据同步，归档信息资源或执行应用程序和库修补。 CI / CD工具通常支持插件市场。例如，詹金斯列出了1500多个插件，这些插件支持与第三方平台，用户界面，管理，源代码管理和构建管理的集成。

一旦选择了CI / CD工具，开发团队必须确保在应用程序外部配置了所有环境变量。 CI / CD工具允许设置这些变量，掩盖变量（例如密码和帐户密钥）以及在为目标环境部署时对其进行配置。

 

CD工具还提供仪表板和报告功能。如果构建或交付失败，它们会警告开发人员有关失败的信息。它们与版本控制和敏捷工具集成在一起，因此可以用来查找哪些代码更改和用户案例构成了构建。

 

使用Kubernetes和无服务器架构实现CI / CD管道

在云环境中运行CI / CD管道的许多团队还使用诸如Docker之类的容器和诸如Kubernetes之类的编排系统。容器允许以标准的便携式方式进行包装和运输。容器使轻松地扩展或拆除具有可变工作负载的环境成为可能。

 

有很多方法可以将容器，基础结构用作代码以及CI / CD管道一起使用。您可以通过完成教程（例如使用Jenkins的Kubernetes或使用Azure DevOps的Kubernetes）来探索这些选项。

 

无服务器计算架构为部署和扩展应用程序提供了另一种途径。在无服务器环境中，基础架构由云服务提供商完全管理，并且应用程序根据其配置根据需要消耗资源。例如，在AWS上，无服务器应用程序可以作为Lambda函数运行，并且可以使用插件将部署集成到Jenkins CI / CD管道中。

1.5 CI / CD支持更频繁的代码部署

概括地说，CI打包和测试软件会构建并警告开发人员，如果他们的更改未通过任何单元测试。 CD是自动化的工具，可以对基础结构进行更改并执行其他测试。

 

CI / CD管道是为希望经常改进应用程序并需要可靠的交付过程的企业而设计的。标准化构建，开发测试和自动化部署的额外工作是用于部署代码更改的制造过程。一旦到位，它使团队可以专注于增强应用程序的过程，而不必关注将其交付给计算环境的系统细节。

 

[通过InfoWorld Daily新闻通讯了解软件开发，云计算，数据分析和机器学习方面的最新发展]

CI / CD是一种最佳的开发实践，因为它可以解决希望频繁推送更改的开发人员与需要稳定应用程序的操作之间的错位。有了自动化，开发人员可以更频繁地推动变更。运营团队看到了更高的稳定性，因为环境具有标准配置，交付过程中进行了连续测试，环境变量与应用程序分离，并且回滚过程是自动化的。

 

可以将CI / CD管道实施的影响作为devops关键绩效指标（KPI）进行衡量。当实施具有连续测试的CI/ CD时，通常会改善KPI，例如部署频率，更改提前期和从事件中恢复的平均时间（MTTR）。但是，CI / CD只是可以推动这些改进的一个过程，而提高部署频率还存在其他先决条件。

 

CI / CD入门要求开发团队和运营团队就技术，实践和优先级进行协作。团队需要就其业务和技术的正确方法达成共识，以便一旦CI / CD到位，团队就将始终遵循以下惯例。