在 CI/CD 和 DevOps 领域中,持续交付和持续部署是一个老生常谈的话题。持续集成这个术语最早是在1994年由 Grady Booch 提出。微服务提出者 Martin Flower 在2014年发表的论文《Microservice》中也对软件开发持续集成提供了可参考原则。
持续集成是借助工具对软件项目进行持续的自动化的编译打包构建测试发布,来检查软件交付质量的一种行为。而持续部署是基于持续交付的优势自动将经过测试的代码推入生产环境的过程。下文从细节描述了持续集成和持续部署各阶段的关键步骤,以下是原文。
本文将探讨CI(持续集成)/CD(持续部署)流程中的各个阶段;以及从快速、规模交付的视角探讨为什么CI/CD流水线对于我们的组织是必不可少的。
CI/CD流水线工作流包括CI/CD流程开始时所有阶段等一系列步骤,负责创建自动、连贯的软件交付模型。
通过 CI/CD 流水线,软件研发可以实现从代码签入、测试、构建和部署直至生产阶段都在流水线中向前推进。此概念之所以高大上,是因为一旦实施了流水线,就可以将其部分或全部自动化,从而加快开发流程并减少错误。
换句话说,CI/CD流水线使企业可以更轻松地应对软件的自动、快速、持续交付。
DevOps 工程师经常会将 CI/CD 各阶段的和其 CI/CD 流水线混淆。尽管不同的工具可以将每个复杂阶段自动化完成分阶段的CI/CD,但是整体CI/CD软件链仍然可能由于不可避免的人工干预而中断。
因此我们首先需要了解CI/CD流程中的各个阶段,以及从快速、规模交付的视角探讨为什么CI/CD流水线对于我们的组织是必不可少的。
CI/CD 阶段:理解参与者、流程、技术
企业应用程序开发参与者通常由开发人员,测试人员/QA工程师,运维工程师以及SRE(站点可靠性工程师)或IT运营团队组成。他们紧密合作,目标是高质量软件交付。CI/CD是两个独立过程的组合:持续集成和持续部署。下面列出了每个步骤中的主要步骤:
持续集成(CI)是构建软件和完成初始测试的过程。持续部署(CD)是将代码与基础设施相结合的过程,确保完成所有测试并遵循策略,然后将代码部署到预期环境中。当然,许多公司也有自己特有流程,但主要步骤如下。
CI:代码提交阶段
CI:静态代码检查阶段
将额外的策略检查加入自动化流水线中可以显著减少流程中稍后发现的错误数量。
CI:构建
.exe
,.dll
,.jar
等)。在构建过程中,还可以生成SQL脚本,配合基础设施配置文件一起进行测试。简而言之,构建阶段就是编译应用程序的阶段。Artifactory存储、构建验证测试和单元测试也可以作为构建过程的一部分。构建验证测试(BVT)/冒烟测试/单元测试:
创建构建后立即执行冒烟测试。BVT将检查所有模块是否正确集成,以及程序的关键功能是否正常运行。这样做的目的是拒绝严重损坏的应用程序,以使QA团队不会在安装和测试软件应用程序步骤浪费时间。
在完成这些检查后,将向流水线中执行UT(单元测试),以进一步减少生产中的故障。单元测试可验证开发人员编写的单个单元或组件是否按预期执行。
构建产物存储:
一旦构建就绪,程序包就会存储在称为 Artifactory 或 Repository 工具的中央数据库。随着每天构建量的增加,跟踪所有构建产物也会变得愈加困难。因此,一旦生成并验证了构建产物,就将其发送到存储库进行存储管理。诸如 Jfrog Artifactory 之类的存储库工具可用于存储诸如 .rar
,.war
,.exe
,Msi
等之类的二进制文件。测试人员可以从此处手动进行选择,并在测试环境中部署构建产物以进行测试。
CI:测试阶段
测试人员(或称为QA工程师)基于用户描述的测试用例和场景设置自动化测试用例。他们执行回归分析、压力测试来检查与预期输出的偏差。测试中涉及的活动有完整性测试、集成测试、压力测试。这是一个高层次测试方法。在这个阶段,可以发现开发人员忽视的某些代码问题。
集成测试:
集成测试是使用Cucumber、Selenium等工具执行的,在这些工具中,单个应用程序模块被组合起来并作为一组进行测试,同时评估其是否符合指定的功能需求。在集成测试之后,需要有人批准该组中的更新集应该移到下一个阶段,这通常是性能测试。这个验证过程可能很麻烦,但它是整个过程的一个重要部分。验证这个过程业界有很多优秀的方案。
性能和压力测试:
Selenium、JMeter等自动化测试工具也可执行性能和压力测试,以检查应用程序在面对高负载时是否稳定和性能良好。该测试流程通常不会在每个更新提交上运行,因为完整的压力测试是长期运行的。当发布主要的新功能时,将对多个更新进行分组,并完成完整的性能测试。在单个更新被转移到下一阶段的情况下,流水线可能将金丝雀测试加入作为可选。
CD:Bake
Baking是指在生产时使用当前配置从源代码创建不可变的镜像实例。这些配置可能是数据库更改和其他基础结构更新之类的事情。Spinnaker可以触发Jenkins执行此任务,并且某些组织更喜欢使用Packer。
CD:部署
Spinnaker自动将已bake的镜像发送到部署阶段。这是将服务器组设置为部署到集群的位置。与上述测试过程类似,在部署阶段将执行功能相同的过程。首先将部署移至测试阶段,然后最终移至生产环境,以进行批准和检查。这个处理过程可以由Spinnaker等工具支持。
CD:验证
这也是团队优化整个CI/CD流程的关键位置。因为现在已经进行了如此多的测试,所以失败很少见。但是,此时必须尽快解决所有故障,以最大程度地减少对最终客户的影响。团队也应该考虑使流程的这一部分自动化。
使用蓝绿部署、金丝雀分析、滚动更新等策略部署到产品。在部署阶段,将监视正在运行的应用程序以验证当前部署是否正确或是否需要回滚。
CD:监控
持续交付(CD):反馈和协作工具
企业必须评估一个整体的持续交付解决方案,该解决方案可以自动化或促进上述这些阶段的自动化。
原文链接:https://www.opsmx.com/blog/what-is-a-ci-cd-pipeline/