[TOC]
本项目是百姓网DevOps团队基于现有工作提炼出来的相对表完整的流水线,项目功能是一个简单的用户信息的增删改查,采用SpringBoot框架开发,数据库采用H2。
对应的API为:
API列表 | 路径 | 请求方式 | 参数说明 |
---|---|---|---|
项目首页 | / | GET | 无 |
查询用户 | api/user/list | GET | 无 |
新增用户 | api/user/create | POST | { "name": "messi", "age": 30 } |
更新用户 | api/user/update | POST | { "id": 1, "age": 40 } |
删除用户 | api/user/remove?id=${id} | POST | ${id}代表用户id |
开发环境访问:http://dev-devops.baixing.cn:8088/
测试环境访问:http://test-devops.baixing.cn:8088/
预发环境访问:http://stg-devops.baixing.cn:8088/
产线环境访问:http://prod-devops.baixing.cn:8088/
百姓网DevOps团队成员介绍:
- 王翱
- 李如磊
- 高榕
- 王东兴
- 虞伟
-
分支策略
- 采用小步快跑的模式
- 在流程设计上,master 作为发布分支,release-* 为提测分支,提测分支是短期的
- 在 release 测试过程中,发现某个 feature 的 bug, 直接从 release 分支 checkout 出来进行修复,并再次合入 release
-
流水线说明
流水线包含以下几个步骤:
- 编译
- 代码检查 && 单元测试
- 生成可执行文件并提交
- 生成镜像文件并提交
- 部署对应环境
- 自动化测试
- 发布生产(该步骤只在上线时启用)
- 清理 && TAG
部署采用Gitops相关的工作流进行实践,结合Gitlab和ArgoCD进行持续交付
介绍下本次演示所使用到的工具链和对应的访问地址
- 基础环境:
- 代码
- 技术框架:SpringBoot
- 数据库:H2
- 持续集成
- 代码版本库:Gitlab:https://gitlab.com/baixingwang/devops-user-service
- 编译工具:Maven
- 代码质控:Sonar:http://39.100.144.36/projects
- 单侧覆盖度:Jacoco
- 制品管理:JFrog:http://52.82.40.171:8082/ui/packages/gav:%2F%2Fcom.baixingwang:devops-user-service?name=devops&type=packages
- 项目管理:TAPD
- 接口测试:Yapi
- 性能测试:Jmeter
- 持续部署
- 容器技术:Docker
- 容器声明管理:Kustomize
- 部署工具:ArgoCD:https://a28216abd3b7343ff97a18868cd62626-894254263.cn-northwest-1.elb.amazonaws.com.cn:8888/applications
- 灰度发布:Flagger
- 可观测性
- 可视化度量:Prometheus+Grafana:http://ad853aa0d7e1c4e8aba01298e8753c3a-1552531560.cn-northwest-1.elb.amazonaws.com.cn:3000/d/vu8e0VWZk/istio-performance-dashboard?orgId=1&refresh=10s
- 全链路:Elastic APM:https://8a639b1c32ea43df8f6d9157eb6e2ef8.ap-southeast-1.aws.found.io:9243/app/apm#/services/devops-user-service/transactions?rangeFrom=now-15m&rangeTo=now&transactionType=request
以下会从十个维度对整个流水线运行过程进行详细说明并附上关键截图,供各位参考
本次演示项目采用一个简单的微服务作为流水线的演示,需求相对比较简单。需要完成一个【用户管理】的模块,需要实现的功能有:
- 用户信息的管理,包括新增、修改、查询和删除
- 用户信息包括用户姓名和用户年龄
【说明】:本次演示项目技术选型为SpringBoot,数据库采用内存数据库h2
需求管理采用工具为TAPD,具体拆分为【需求】-【子需求】-【任务】,具体的任务对应到相关研发人员,并评估工作时间。
工作量在Scrum计划会议上全员进行参与,在【理解用户故事】和【拆分功能点】后进行,所有工作量必须透明公开,承诺在计划能完成。在TAPD上输入【预计开始】和【预计结束】时间
我们在TAPD上将需求和Gitlab代码库进行关联,在小组成员提交代码时需要明确关联的需求。
同时可以看到该项目中代码提交的统计数据
代码管理库采用Gitlab进行版本管理,项目代码地址为:https://gitlab.com/baixingwang/devops-user-service
本次演示项目分支策略比较简单,采用【master】作为主干分支策略,简单说明如下:
- feature分支
- 功能分支
- release分支
- 提测分支
- 编译、测试、单测覆盖度、代码质量、测试环境部署等均在该分支上进行
- master分支
- 部署分支
- 完成测试流程后,合并到该分支进行上线部署
上线发版时需要将代码合并入master分支,此时需要人工进行代码审核,确认无误后进行发布线上流程,此步骤也是本次演示中唯一的人工介入的部分
本次项目采用的制品库有两个:
软件版本号由四部分组成:
- 第一个1为主版本号
- 第二个1为子版本号
- 第三个1为阶段版本号
- 第四部分为发布版本号,主要有2个,分别是
SNAPSHOT
和RELEASE
例如:1.1.1.RELEASE
主版本号(1):当功能模块有较大的变动,比如增加多个模块或者整体架构发生变化
子版本号(1):当功能有一定的增加或变化,比如增加了对权限控制、增加自定义视图等功能
阶段版本号(1):一般是 Bug 修复或是一些小的变动,要经常发布修订版,时间间隔不限,修复一个严重的bug即可发布一个修订版
发布版本号(RELEASE):此版本号用于标注当前版本的软件处于哪个发布阶段,当软件进入到发布阶段时需要修改此版本号
代码中配置仓库地址,确保对应的依赖从制品库中进行下载,参考【pom.xml】
本次自动化构建以来【Gitlab Runner】进行,相关脚本参考项目路径下的【.gitlab-ci.yml】:
https://gitlab.com/baixingwang/devops-user-service/-/blob/master/.gitlab-ci.yml
在整个CI流程中,存在两种级别的复用:
-
依赖JAR包的服务,采用CI缓存进行实现,避免每次都下载依赖,下图说明缓存生效
-
项目打包完成后,需要传到【app.jar】供生成docker镜像,以下为两个阶段的依赖传递
【package】阶段最后上传app.jar
【docker-build】阶段下载app.jar用来构建镜像
设置每天自动构建的任务,目标为dev分支,构建完毕后自动部署至测试环境
采用Gitlab Runner进行构建,并行构建的时候自动化选择不同的Runner进行,以下两个构建阶段采用了不同的Runner进行
项目团队成员提交代码变更后自动触发CI流程,以下是两位不同的项目成员触发的CI流程
提交代码变更后后自动触发,限定分支位feature分支
流水线执行结果通过邮件和企业微信到达项目成员,如果构建失败,通过详情信息直接关联到对应的构建任务,查看失败原因。以下是企业微信的相关截图
每次代码变更触发持续集成时,都会进行自动化单元测试,在流水线配置时单独配置一个单测阶段
以下是执行日志输出和测试结果
针对service层做单元测试,并通过Jacoco生成单元测试覆盖度报告
同时在【ReadME】文件中生成覆盖度标签
使用YPAI平台进行接口协议管理及自动化用例执行,其他依赖前置后置操作能力,由自研服务支持。
本次项目代码质量管控采用Sonar
同时引入阿里代码规范作为代码检测规则:
引入sonar自动化检测插件,在流水线中单独创建一个任务进行自动化代码质量管控,为了加快速度,和单元测试并行处理
登录sonar即可查看代码质量报告
代码提交变更后自动触发流水线,流水线的整个生命周期中只有上线合并代码的确认环节需要人为干预,其他均为自动化处理
本次演示包括四个环境:
- 开发环境
- 测试环境
- 预发布环境
- 产线环境
具体说明见【第10部分】
项目部署在k8s中,配置可以通过ConfigMap来进行读取,做到应用和配置分离的效果
在Gitlab中可以展示流水线先的DAG图
利用flagger组件进行灰度发布,灰度发布示意图和执行日志如下
本次演示项目准备了四个环境,以下是环境说明和访问地址
环境 | 说明 | 访问地址 |
---|---|---|
开发环境(dev) | 功能自测试 | dev-devops.baixing.cn:8088 |
测试环境(test) | 包括功能测试、集成测试和压力测试等 | test-devops.baixing.cn:8088 |
预发布环境(stg) | 上线前的回归,和真实环境基本一致 | stg-devops.baixing.cn:8088 |
产线环境(prod) | 最终产线环境 | prod-devops.baixing.cn:8088 |
由于机器数量的限制,环境交付采用k8s的namespace做逻辑隔离
本次项目最终线上监控采用【Metrics】+ 【Log】+ 【Tracing】
通过Fluntd采集日志文件,并输出到ES集群中,研发人员通过kibana可以查询对应服务的日志
埋点数据指标通过Prometheus+Grafana进行展示,可以进行自定义
同时数据会进入ElasticStack中,通过Kibana进行展示
链路追踪依赖APM组件,在Kibana中进行展示