DevOps流水线落地实践

2,723 阅读11分钟

本篇文章是参加【首届中国DevOps社区流水线大赛】的最终交付文档,是我们团队根据实际生产落地出来的最佳实践

1、总体说明

1.1、项目说明

本项目是百姓网DevOps团队基于现有工作提炼出来的相对表完整的流水线,项目功能是一个简单的用户信息的增删改查,采用SpringBoot框架开发,数据库采用H2。

对应的API为:

API列表路径请求方式参数说明
项目首页/GET
查询用户api/user/listGET
新增用户api/user/createPOST{ "name": "messi", "age": 30 }
更新用户api/user/updatePOST{ "id": 1, "age": 40 }
删除用户api/user/remove?id=${id}POST${id}代表用户id

开发环境访问:dev-devops.baixing.cn:8088/

测试环境访问:test-devops.baixing.cn:8088/

预发环境访问:stg-devops.baixing.cn:8088/

产线环境访问:prod-devops.baixing.cn:8088/

image-20201015100933256

1.2、流水线说明

  • 分支策略

    • 采用小步快跑的模式
    • 在流程设计上,master 作为发布分支,release-* 为提测分支,提测分支是短期的
    • 在 release 测试过程中,发现某个 feature 的 bug, 直接从 release 分支 checkout 出来进行修复,并再次合入 release

    img

  • 流水线说明

    流水线包含以下几个步骤:

    • 编译
    • 代码检查 && 单元测试
    • 生成可执行文件并提交
    • 生成镜像文件并提交
    • 部署对应环境
    • 自动化测试
    • 发布生产(该步骤只在上线时启用)
    • 清理 && TAG

1.4、部署交付

部署采用Gitops相关的工作流进行实践,结合Gitlab和ArgoCD进行持续交付

GitOps Workflow

1.5、工具链

介绍下本次演示所使用到的工具链和对应的访问地址

1.5、演示说明

以下会从十个维度对整个流水线运行过程进行详细说明并附上关键截图,供各位参考

2、需求管理

2.1、需求说明

本次演示项目采用一个简单的微服务作为流水线的演示,需求相对比较简单。需要完成一个【用户管理】的模块,需要实现的功能有:

  • 用户信息的管理,包括新增、修改、查询和删除
  • 用户信息包括用户姓名和用户年龄

【说明】:本次演示项目技术选型为SpringBoot,数据库采用内存数据库h2

2.2、需求管理

需求管理采用工具为TAPD,具体拆分为【需求】-【子需求】-【任务】,具体的任务对应到相关研发人员,并评估工作时间。

image-20201013095000571

image-20201013095050567

2.3、工作量评估

工作量在Scrum计划会议上全员进行参与,在【理解用户故事】和【拆分功能点】后进行,所有工作量必须透明公开,承诺在计划能完成。在TAPD上输入【预计开始】和【预计结束】时间

image-20201013095716421

2.4、代码库关联

我们在TAPD上将需求和Gitlab代码库进行关联,在小组成员提交代码时需要明确关联的需求。

image-20201013101037123

同时可以看到该项目中代码提交的统计数据

image-20201013170014708

3、代码管理

3.1、代码管理工具

代码管理库采用Gitlab进行版本管理,项目代码地址为:gitlab.com/baixingwang…

3.2、分支管理

本次演示项目分支策略比较简单,采用【master】作为主干分支策略,简单说明如下:

  • feature分支
    • 功能分支
  • release分支
    • 提测分支
    • 编译、测试、单测覆盖度、代码质量、测试环境部署等均在该分支上进行
  • master分支
    • 部署分支
    • 完成测试流程后,合并到该分支进行上线部署

image-20201016103056983

3.3、代码审查

上线发版时需要将代码合并入master分支,此时需要人工进行代码审核,确认无误后进行发布线上流程,此步骤也是本次演示中唯一的人工介入的部分

image-20201014172731484

4、制品管理

4.1、统一制品库

本次项目采用的制品库有两个:

  • 项目依赖制品库:nexus

    image-20201013113037369

  • Docker镜像制品库:Gitlab Registry

4.2、版本号管理

软件版本号由四部分组成:

  • 第一个1为主版本号
  • 第二个1为子版本号
  • 第三个1为阶段版本号
  • 第四部分为发布版本号,主要有2个,分别是SNAPSHOTRELEASE

例如:1.1.1.RELEASE

主版本号(1):当功能模块有较大的变动,比如增加多个模块或者整体架构发生变化

子版本号(1):当功能有一定的增加或变化,比如增加了对权限控制、增加自定义视图等功能

阶段版本号(1):一般是 Bug 修复或是一些小的变动,要经常发布修订版,时间间隔不限,修复一个严重的bug即可发布一个修订版

发布版本号(RELEASE):此版本号用于标注当前版本的软件处于哪个发布阶段,当软件进入到发布阶段时需要修改此版本号

image-20201019135904596

4.3、依赖组件管理

代码中配置仓库地址,确保对应的依赖从制品库中进行下载,参考【pom.xml】

image-20201013104735168

5、构建方式

5.1、自动化构建脚本

本次自动化构建以来【Gitlab Runner】进行,相关脚本参考项目路径下的【.gitlab-ci.yml】:

gitlab.com/baixingwang…

image-20201016110755961

5.2、模块级别复用

在整个CI流程中,存在两种级别的复用:

  • 依赖JAR包的服务,采用CI缓存进行实现,避免每次都下载依赖,下图说明缓存生效

    image-20201013114659560

    image-20201013114803908

  • 项目打包完成后,需要传到【app.jar】供生成docker镜像,以下为两个阶段的依赖传递

    image-20201013115128606

    【package】阶段最后上传app.jar

    image-20201013115257567

    【docker-build】阶段下载app.jar用来构建镜像

    image-20201013115357126

5.3、自动构建

设置每天自动构建的任务,目标为dev分支,构建完毕后自动部署至测试环境

image-20201013121131531

5.4、构建资源弹性

采用Gitlab Runner进行构建,并行构建的时候自动化选择不同的Runner进行,以下两个构建阶段采用了不同的Runner进行

image-20201013120348690

image-20201013120503644

6、持续集成

6.1、按需集成

项目团队成员提交代码变更后自动触发CI流程,以下是两位不同的项目成员触发的CI流程

image-20201013134852305

6.2、触发机制

提交代码变更后后自动触发,限定分支位feature分支

image-20201019140334105

6.3、集成结果推送

流水线执行结果通过邮件和企业微信到达项目成员,如果构建失败,通过详情信息直接关联到对应的构建任务,查看失败原因。以下是企业微信的相关截图

  • 构建成功

    image-20201013140419174

    image-20201013140533768

  • 构建失败

    image-20201013140604154

    image-20201013140657049

6.4、自动化测试

每次代码变更触发持续集成时,都会进行自动化单元测试,在流水线配置时单独配置一个单测阶段

image-20201013141148656

以下是执行日志输出和测试结果

image-20201013141241485

image-20201013141301548

7、自动化测试

7.1、测试计划

测试计划使用TAPD平台进行管理,关联需求、用例及缺陷。 image-testplan

7.2、单元测试和覆盖度

针对service层做单元测试,并通过Jacoco生成单元测试覆盖度报告

image-20201016150925063

同时在【ReadME】文件中生成覆盖度标签

image-20201016150947186

7.3、接口测试

image-20201015112907155 使用YPAI平台进行接口协议管理及自动化用例执行,其他依赖前置后置操作能力,由自研服务支持。 image-interface

7.4、性能测试

基于jmeter自研性能测试平台,进行性能测试。 image-stress image-20201015113017795

7.5、测试报告

使用TAPD做测试报告数据收集及发送。 image-report

8、代码质量管控

8.1、质控工具

本次项目代码质量管控采用Sonar

image-20201014102547753

同时引入阿里代码规范作为代码检测规则:

image-20201014102659354

8.2、自动化检测

引入sonar自动化检测插件,在流水线中单独创建一个任务进行自动化代码质量管控,为了加快速度,和单元测试并行处理

image-20201014102948937

image-20201014103023212

8.3、可视化

登录sonar即可查看代码质量报告

image-20201014103236638

9、部署流水线

9.1、自动化

代码提交变更后自动触发流水线,流水线的整个生命周期中只有上线合并代码的确认环节需要人为干预,其他均为自动化处理

image-20201014135600476

9.2、多环境

本次演示包括四个环境:

  • 开发环境
  • 测试环境
  • 预发布环境
  • 产线环境

具体说明见【第10部分】

9.3、应用和配置分离

项目部署在k8s中,配置可以通过ConfigMap来进行读取,做到应用和配置分离的效果

9.4、可视化

在Gitlab中可以展示流水线先的DAG图

image-20201015120152131

9.5、灰度发布

利用flagger组件进行灰度发布,灰度发布示意图和执行日志如下

img

企业微信截图_16027489266827

10、环境管理

10.1、环境确定

本次演示项目准备了四个环境,以下是环境说明和访问地址

环境说明访问地址
开发环境(dev)功能自测试dev-devops.baixing.cn:8088
测试环境(test)包括功能测试、集成测试和压力测试等test-devops.baixing.cn:8088
预发布环境(stg)上线前的回归,和真实环境基本一致stg-devops.baixing.cn:8088
产线环境(prod)最终产线环境prod-devops.baixing.cn:8088

10.2、环境交付

由于机器数量的限制,环境交付采用k8s的namespace做逻辑隔离

企业微信截图_63aac2d6-c729-4df3-bf44-1806b776264d

11、度量可视化

本次项目最终线上监控采用【Metrics】+ 【Log】+ 【Tracing】

11.1、日志

通过Fluntd采集日志文件,并输出到ES集群中,研发人员通过kibana可以查询对应服务的日志

image-20201015145540865

11.2、Metrics

埋点数据指标通过Prometheus+Grafana进行展示,可以进行自定义

image-20201015095040818

同时数据会进入ElasticStack中,通过Kibana进行展示

image-20201015095209548

image-20201015095227567

11.3、Tracing

链路追踪依赖APM组件,在Kibana中进行展示

image-20201015095340138

image-20201015095304146