持续集成 (CI) 和持续交付 (CD),也称为 CI/CD,体现了应用程序开发团队用来更频繁、更可靠地交付代码更改的文化、操作原则和一组实践。
CI/CD 是dvoeps团队的最佳实验。这也是 敏捷方法的最佳实践。通过自动化集成和交付,CI/CD 让软件开发团队专注于满足业务需求,同时确保代码质量和软件安全。
持续集成是一种编码理念和一组实践,它促使开发团队经常实施小的代码更改并将它们签入版本控制存储库。大多数现代应用程序需要使用各种平台和工具开发代码,因此团队需要一致的机制来集成和验证更改。持续集成建立了一种自动化的方式来构建、打包和测试他们的应用程序。拥有一致的集成流程可以鼓励开发人员更频繁地提交代码更改,从而带来更好的协作和代码质量。
持续交付从持续集成结束的地方开始,并自动将应用程序交付到选定的环境,包括生产、开发和测试环境。持续交付是一种将代码更改推送到这些环境的自动化方式。
有助于存储必须与每次交付一起打包的特定于环境的参数。然后 CI/CD 自动化对需要重新启动的 Web 服务器、数据库和其他服务进行任何必要的服务调用。它还可以在部署后执行其他程序。
因为目标是交付高质量的代码和应用程序,所以 CI/CD 还需要 持续测试。在持续测试中,一组自动回归、性能和其他测试在 CI/CD 管道中执行。
拥有强大 CI/CD 管道的成熟 devops 团队也可以实现持续部署,其中应用程序更改通过 CI/CD 管道运行,传递的构建直接部署到生产环境。一些实践持续部署的团队选择每天甚至每小时部署到生产环境,尽管持续部署并不是每个业务应用程序的最佳选择。
实施 CI/CD 管道的组织通常拥有多个 devops 最佳实践,包括微服务开发、无服务器架构、持续测试、基础设施即代码和部署容器。这些实践中的每一个都提高了流程自动化并增加了云计算环境的稳健性。这些实践共同为支持持续部署提供了坚实的基础。
持续集成是一种以流程机制和自动化为后盾的开发理念。在实践持续集成时,开发人员经常将他们的代码提交到版本控制存储库中;大多数团队至少每天都有提交代码的标准。基本原理是,在较小的代码差异上识别缺陷和其他软件质量问题比在长时间开发的较大代码差异上更容易。此外,当开发人员在较短的提交周期上工作时,多个开发人员不太可能编辑相同的代码并在提交时需要合并。
实施持续集成的团队通常从版本控制配置和实践定义开始。尽管经常检查代码,但敏捷团队会在更短和更长的时间范围内开发功能和修复。实践持续集成的开发团队使用不同的技术来控制哪些功能和代码可以投入生产。
许多团队使用功能标志,一种在运行时打开或关闭功能和代码的配置机制。仍在开发中的功能在代码中使用功能标志进行包装,与主分支一起部署到生产环境中,并在它们准备好使用之前关闭。在最近的研究中,使用功能标志的 devops 团队的开发频率增加了九倍。CloudBees、Optimizely、 Rollouts和launchDarkly等功能标记工具与 CI/CD 工具集成以支持功能级配置。
在自动构建过程中,所有软件、数据库和其他组件都打包在一起。例如,如果您正在开发 Java 应用程序,则持续集成会将所有静态 Web 服务器文件(例如 HTML、CSS 和 JavaScript)与 Java 应用程序和任何数据库脚本一起打包。
持续集成不仅打包所有软件和数据库组件,而且自动化还将执行单元测试和其他类型的测试。测试向开发人员提供了重要的反馈,即他们的代码更改没有破坏任何东西。
大多数 CI/CD 工具允许开发人员按需启动构建,由版本控制存储库中的代码提交触发,或者按照定义的时间表。团队需要确定最适合团队规模的构建计划、预期的每日提交数量以及其他应用程序注意事项。最佳实践是确保快速提交和构建;否则,这些过程可能会阻碍团队尝试快速编码和频繁提交。
自动化测试框架帮助质量保证工程师定义、执行和自动化各种类型的测试,这些测试可以帮助开发团队了解软件构建是通过还是失败。它们包括在每个 sprint 结束时开发的功能测试,并汇总到整个应用程序的回归测试中。回归测试会通知团队代码更改是否使一个或多个跨应用程序功能区域开发的测试失败,其中有测试覆盖。
最佳实践是允许并要求开发人员在其本地环境中运行全部或部分回归测试。此步骤可确保开发人员仅在代码更改通过回归测试后将代码提交给版本控制。
然而,回归测试只是开始。Devops 团队还自动化性能、API、浏览器和设备测试。如今,团队还可以在 CI/CD 管道中 嵌入静态代码分析和安全测试、已进行左移测试。敏捷团队还可以使用服务虚拟化测试与第三方 API、SaaS 和其他不受其控制的系统的交互。关键是能够通过命令行、webhook 或 web 服务触发这些测试,并获得成功或失败响应。
持续测试意味着 CI/CD 管道集成了测试自动化。一些单元和功能测试会在持续集成过程之前或期间标记问题。需要完整交付环境的测试(例如性能和安全测试)通常集成到持续交付中,并在构建交付到其目标环境后完成。
持续交付是将应用程序推送到一个或多个交付环境的自动化。开发团队通常有多个环境来暂存应用程序更改以进行测试和审查。devops 工程师使用 CI/CD 工具(例如Jenkins、CircleCI、AWS CodeBuild、Azure DevOps、Atlassian Bamboo、Argo CD、Buddy、Drone 或 Travis CI)来自动执行这些步骤并提供报告。
例如,Jenkins 用户在描述不同阶段(如构建、测试和部署)的jenkinsfile中定义他们的管道。环境变量、选项、密钥、证书和其他参数在文件中声明,然后分阶段引用。帖子部分处理错误情况和通知。
典型的持续交付管道具有构建、测试和部署阶段。在不同阶段可以包括以下活动:
更复杂的持续交付管道可能具有其他步骤,例如同步数据、归档信息资源或修补应用程序和库。
使用持续部署交付生产的团队可能会使用不同的切换实践来最大限度地减少停机时间并管理部署风险。一种选择是配置金丝雀部署,将流量使用从较旧的软件版本转移到较新的软件版本。
CI/CD 工具通常支持插件市场。例如, Jenkins列出了1800对个支持与第三方平台集成、用户界面、管理、源代码管理和构建管理的插件。
一旦开发团队选择了 CI/CD 工具,它必须确保在应用程序外部配置所有环境变量。CI/CD 工具允许开发团队设置这些变量,屏蔽密码和帐户密钥等变量,并在部署时针对目标环境进行配置。
持续交付工具还提供仪表板和报告功能,当 devops 团队实施可观察的CI/CD 管道时,这些功能会得到增强。如果构建或交付失败,开发人员会收到警报。仪表板和报告功能与版本控制和敏捷工具集成,以帮助开发人员确定哪些代码更改和用户故事构成了构建。
实施 CI/CD 管道的影响可以作为devops关键绩效(KPI) 来衡量。部署频率、变更提前期和事故平均恢复时间 (MTTR) 等指标通常可以通过实施 CI/CD 和持续测试来改进。然而,CI/CD 只是推动这些改进的一个过程,提高部署频率还有其他先决条件
许多在云环境中运行 CI/CD 管道的团队也使用Docker等容器和kubernetes等编排系统 。容器允许以标准、便携的方式进行包装和运输应用。容器可以轻松扩展或拆除具有可变工作负载的环境。
有许多方法可以一起使用容器、基础设施即代码 (IaC) 和 CI/CD 管道。免费教程(例如kubernetes与Jenkins或kubernetes与Azure DevOps)可以帮助您探索您的选择。
另一种选择是使用无服务器架构来部署和扩展您的应用程序。在无服务器环境中,云服务提供商管理基础设施,应用程序根据其配置按需消耗资源。例如,在 AWS 上,无服务器应用程序作为Lambda函数运行,部署可以通过插件 集成到 Jenkins CI/CD 管道中。Azure 无服务器和GPS 无服务器计算是类似的服务。
您可能想知道 CI/CD 管道开发和管理的一些更高级的领域。以下是一些值得注意的:
回顾一下,持续集成打包和测试软件构建并在他们的更改未通过任何单元测试时提醒开发人员。持续交付是向运行时基础架构交付应用程序、服务和其他技术部署并可能执行额外测试的自动化。
对于经常改进应用程序并需要可靠交付流程的企业来说,开发 CI/CD 管道是一种标准做法。一旦到位,CI/CD 管道让团队更多地关注增强应用程序,而不是关注将其交付到各种环境的细节。
开始使用CI/CD需要 devops 团队在技术、实践和优先级上进行协作。团队需要就其业务和技术的正确方法达成共识。一旦管道到位,团队应该始终如一地遵循 CI/CD 实践。