CI/CD 是 devops 和敏捷开发的最佳实践。以下是软件开发团队如何通过 CI/CD 管道实现持续集成和交付自动化。
CI/CD 代表什么？
持续集成（CI）和持续交付（CD），也称为 CI/CD，体现了一种文化和一套运行原则与实践，应用程序开发团队利用它来更频繁、更可靠地交付代码变更。
CI/CD 是开发团队的最佳实践。它也是敏捷方法论的最佳实践。通过自动化代码集成和交付，CI/CD 可让软件开发团队专注于满足业务需求，同时确保软件的高质量和安全性。
CI/CD 的定义
持续集成是一种编码理念和一系列实践，它促使开发团队频繁地实施小的代码变更，并将其检查到版本控制库中。大多数现代应用程序需要使用各种平台和工具开发代码，因此团队需要一种一致的机制来集成和验证变更。持续集成为应用程序的构建、打包和测试提供了一种自动化方式。拥有一致的集成流程可以鼓励开发人员更频繁地提交代码变更，从而提高协作性和代码质量。
持续交付是持续集成的延续，它将应用程序自动交付到选定的环境，包括生产、开发和测试环境。持续交付是将代码变更推送到这些环境的自动化方式。
自动化 CI/CD 管道
CI/CD 工具有助于存储每次交付时必须打包的特定环境参数。然后，CI/CD 自动化会对网络服务器、数据库和其他需要重新启动的服务进行必要的服务调用。它还可以在部署后执行其他程序。
由于目标是交付高质量的代码和应用程序，CI/CD 还需要持续测试。在持续测试中，一组自动化回归、性能和其他测试在 CI/CD 管道中执行。
拥有强大 CI/CD 管道的成熟 devops 团队还可以实施持续部署，在这种情况下，应用程序的更改会通过 CI/CD 管道运行，通过的构建会直接部署到生产环境中。一些实施持续部署的团队选择每天甚至每小时向生产环境部署一次，但持续部署并不是每个业务应用程序的最佳选择。
实施 CI/CD 管道的组织通常会采用多种 devops 最佳实践，包括微服务开发、无服务器架构、持续测试、基础设施即代码和部署容器。这些实践中的每一个都能改善流程自动化，提高云计算环境的稳健性。这些实践共同为支持持续部署奠定了坚实的基础。
持续集成如何改善协作和代码质量
持续集成是一种以流程机制和自动化为支撑的开发理念。在实施持续集成时，开发人员要频繁地将代码提交到版本控制库中；大多数团队的标准是至少每天提交一次代码。这样做的理由是，在较小的代码差异上发现缺陷和其他软件质量问题要比在长期开发的较大代码差异上发现缺陷和其他软件质量问题容易得多。此外，当开发人员的提交周期较短时，多个开发人员编辑相同代码并在提交时要求合并的可能性较小。
实施持续集成的团队通常从版本控制配置和实践定义开始。虽然检查代码的频率很高，但敏捷团队开发功能和修复的时间却有长有短。实施持续集成的开发团队使用不同的技术来控制哪些功能和代码可以投入生产。
许多团队使用特性标志，这是一种在运行时打开或关闭功能和代码的配置机制。仍在开发中的功能会在代码中用特性标志包裹起来，与主分支一起部署到生产环境，并在准备好使用之前关闭。最近的研究表明，使用特性标志的DevOps团队的开发频率增加了9倍。特性标志工具，如CloudBees、Optimizely Rollouts和LaunchDarkly，与CI/CD工具集成，支持特性级配置。
在自动化构建过程中
所有软件、数据库和其他组件都被打包在一起。例如，如果你正在开发一个Java应用程序，持续集成将会把所有静态Web服务器文件（如HTML、CSS和JavaScript）以及Java应用程序和任何数据库脚本一起打包。 持续集成不仅打包了所有软件和数据库组件，而且自动化将执行单元测试和其他类型的测试。测试为开发人员提供了重要的反馈，告诉他们代码更改没有破坏任何东西。
大多数CI/CD工具允许开发人员按需启动构建，可以由版本控制存储库中的代码提交触发，也可以按照定义的时间表触发。团队需要确定最适合团队规模、预期每日提交次数以及其他应用程序考虑因素的构建计划。最佳实践是确保提交和构建速度快；否则，这些过程可能会阻碍试图快速编码和频繁提交的团队。
持续测试和安全自动化
自动化测试框架帮助质量保证工程师定义、执行和自动化各种类型的测试，这有助于开发团队了解软件构建是否通过或失败。它们包括在每个迭代周期结束时开发的功能测试，并将其汇总成整个应用程序的回归测试。回归测试向团队提供了关于代码更改是否未通过应用程序各功能区域的测试的信息，这些区域具有测试覆盖。
最佳实践是启用并要求开发人员在其本地环境中运行所有或部分回归测试。这一步确保开发人员只有在代码更改通过回归测试后才将代码提交到版本控制中。
然而，回归测试只是开始。DevOps团队还会自动化性能、API、浏览器和设备测试。如今，团队还可以在CI/CD流水线中嵌入静态代码分析和安全测试，以进行向左移动的测试。敏捷团队还可以使用服务虚拟化测试与第三方API、SaaS和其他系统之间的交互，这些系统位于他们无法控制的范围之外。关键在于能够通过命令行、webhook或Web服务触发这些测试，并获得成功或失败的响应。
持续测试意味着CI/CD流水线集成了测试自动化。一些单元测试和功能测试会在持续集成过程中或之前标识出问题。而那些需要完整交付环境的测试，比如性能测试和安全测试，通常会集成到持续交付流程中，并在构建交付到目标环境后进行。
持续交付的各个阶段
持续交付是将应用程序自动推送到一个或多个交付环境的过程。开发团队通常会拥有多个环境，用于对应用程序变更进行测试和审查。一位DevOps工程师使用诸如Jenkins、CircleCI、AWS CodeBuild、Azure DevOps、Atlassian Bamboo、Argo CD、Buddy、Drone或Travis CI等CI/CD工具来自动化这些步骤并提供报告。
例如，Jenkins用户可以在Jenkinsfile中定义他们的流水线，描述不同的阶段，如构建、测试和部署。文件中声明环境变量、选项、密钥、证书和其他参数，然后在各个阶段中引用这些参数。post部分处理错误条件和通知。
一个典型的持续交付流水线包括构建、测试和部署阶段。以下活动可能包括在不同的阶段：
- 从版本控制中拉取代码并执行构建。
- 启用阶段门，进行自动化安全、质量和合规性检查，并在需要时支持审批。
- 执行任何必要的基础设施步骤，自动化为代码构建或拆除云基础设施。
- 将代码移动到目标计算环境。
- 管理环境变量并为目标环境配置它们。
- 将应用程序组件推送到适当的服务，如Web服务器、API和数据库服务。
- 执行任何需要重新启动服务或调用新代码推送所需的服务端点的步骤。
- 执行持续测试并在测试失败时回滚环境。
- 提供交付状态的日志数据和警报。
- 更新配置管理数据库并在完成部署时向IT服务管理工作流发送警报。
更复杂的持续交付流水线可能会包括其他步骤，如数据同步、信息资源归档或应用程序和库的打补丁。
团队在使用持续部署来交付到生产环境时，可能会采用不同的切换实践来最小化停机时间并管理部署风险。其中一种选择是配置金丝雀部署，通过有序地将流量使用从旧软件版本转移到新版本来实现。
什么是 CI/CD 工具和插件
CI/CD工具通常支持插件市场。例如，Jenkins列出了超过1800个插件，支持与第三方平台、用户界面、管理、源代码管理和构建管理的集成。
一旦开发团队选择了一个CI/CD工具，就必须确保所有环境变量都在应用程序之外进行了配置。CI/CD工具允许开发团队设置这些变量，对密码和账户密钥等变量进行脱敏，并在部署到目标环境时配置这些变量。
持续交付工具还提供仪表板和报告功能，当DevOps团队实施可观察的CI/CD流水线时，这些功能得到了增强。如果构建或交付失败，开发人员会收到警报。仪表板和报告功能与版本控制和敏捷工具集成，帮助开发人员确定构建中包含了哪些代码更改和用户故事。这样的集成能够提供更好的可视化和跟踪，使团队更容易识别和解决问题，并改进持续交付流程。
