基于gitlab的CICD流程规范

前言&＃xff1a;这篇文章主要讲一讲基于gitlab的CICD流程规范

一、简介

为了提升线下测试效率&＃xff0c;缩短测试时间&＃xff0c;提升提测代码质量&＃xff0c;规范流程&＃xff0c;缩短测试准备和执行时间&＃xff0c;缩短问题定位时间&＃xff0c;提供预测性指标&＃xff0c;规范CICD流程&＃xff0c;以提升整体团队效率。

二、CICD流程图

三、CICD说明

发布分为大致三个环境&＃xff1a;
1、开发环境对应于dev分支
2、测试环境对应于test分支
3、预发布环境对应uat分支
4、生产环境对应于master分支

CICD流程如下&＃xff1a;

#开发环境
推送代码->编译->生成的jar包发布到私服->打包为docker镜像->推送到Harbor镜像仓库->部署到k8s集群->健康检查&＃xff08;成功&＃xff0c;微信通知&＃xff0c;c结束返回成功|失败&＃xff0c;微信通知&＃xff0c;ci结束返回失败

#测试环境
1、推送代码->编译->生成的jar包发布到私服->打包为docker镜像->推送到Harbor镜像仓库&＃xff08;成功&＃xff0c;微信通知&＃xff0c;c结束返回成功|失败&＃xff0c;微信通知&＃xff0c;ci结束返回失败&＃xff09;
2、测试人员触发部署到k8s集群->健康检查&＃xff08;成功&＃xff0c;微信通知&＃xff0c;c结束返回成功|失败&＃xff0c;微信通知&＃xff0c;ci结束返回失败&＃xff09;

预发布环境
1、推送代码->编译->生成的jar包发布到私服->打包为docker镜像->推送到Harbor镜像仓库&＃xff08;成功&＃xff0c;微信通知&＃xff0c;c结束返回成功|失败&＃xff0c;微信通知&＃xff0c;ci结束返回失败&＃xff09;
2、测试人员|运维人员 触发部署到k8s集群->健康检查&＃xff08;成功&＃xff0c;微信通知&＃xff0c;c结束返回成功|失败&＃xff0c;微信通知&＃xff0c;ci结束返回失败&＃xff09;

生产环境
1、推送代码->编译->生成的jar包发布到私服->打包为docker镜像->推送到Harbor镜像仓库&＃xff08;成功&＃xff0c;微信通知&＃xff0c;c结束返回成功|失败&＃xff0c;微信通知&＃xff0c;ci结束返回失败&＃xff09;
2、运维人员 触发部署到k8s集群->健康检查&＃xff08;成功&＃xff0c;微信通知&＃xff0c;c结束返回成功|失败&＃xff0c;微信通知&＃xff0c;ci结束返回失败&＃xff09;

实现效果如下&＃xff1a;
1、自动触发构建-test

2、自动触发构建-master&＃xff08;人工确认部署&＃xff09;

实现细节如下&＃xff1a;

步骤为&＃xff1a;
1、配置环境变量
2、拉取代码
3、编译(打包和推送到私服)
4、编译产物修改名称(用作部署指定版本)
5、运行程序
6、反馈编译状态结果

四、结合CICD流程拓展

1、业务代码-数据库基于flyway实现版本控制

引入原因&＃xff1a;

• Schema 变更往往会添加或重命名多个列或表。如果应用程序版本与 schema 版本不匹配&＃xff0c;还有可能彻底破坏应用程序的正常运行。最后&＃xff0c;由于存在两套不同的系统&＃xff0c;通过应用程序升级来协调数据库变更也比较困难。

2、数据库版本控制

FlyWay 允许用户轻松创建各数据库版本、跟踪数据库迁移并轻松完成 schema 变更的前滚与回滚——整个过程无需配合定制构建解决方案。

3、二进制或内置

可以选择在应用程序的启动过程中、或者以二进制可执行文件的形式运行 Flyway。用户可以在代码中直接使用此工具&＃xff0c;使其在启动时能够检查版本功能并运行适当迁移&＃xff0c;从而令数据库与应用程序的版本保持同步。当然也可以临时运行 cmd 行&＃xff0c;在无需重建整体应用程序的前提下为现有数据库提供良好的灵活性。

使用后操作数据库的改变&＃xff1a;
对于数据库表接口的变更就要关闭这几个途径

1. 直接通过工具登录数据去修改表结构
2. 已经发布的sql脚本不允许修改

正确的表结构调整途径&＃xff1a;
在flyway脚本配置路径下编写新的脚本&＃xff0c;启动程序来执行变更。这样可以获得几个很大的好处&＃xff1a;

1. 脚本受Git版本管理控制&＃xff0c;可以方便的找到过去的历史
2. 脚本在程序启动的时候先加载&＃xff0c;再提供接口服务&＃xff0c;一起完成部署步骤
3. 所有表结构的历史变迁&＃xff0c;在管理目录中根据版本号就能很好的追溯

五、代码质量检查及自动化测试&＃xff08;未来&＃xff09;

开发层面建议&＃xff1a;

1. 每次 Review 的代码量不要太多&＃xff0c;控制在 400 行以内
2. 最好的建议是将一次 Review 的时间控制在 60 分钟以内
3. 提交 Review 之前&＃xff0c;需要做严格的自我检查&＃xff0c;根据 Checklist

引入原因&＃xff1a;

• 与动态分析相比&＃xff0c;执行速度更快&＃xff1b;
• 可以对代码质量维护进行自动化&＃xff1b;
• 在早期阶段 (尽管不是所有阶段) 可以自动检索 bug&＃xff1b;
• 在早期阶段可以自动发现安全问题&＃xff1b;

SonarQube 是一种很流行的静态分析工具&＃xff0c;用于持续检查代码库的代码质量和安全性&＃xff0c;并在代码评审期间指导开发团队。SonarQube 可与 CI/CD 集成&＃xff0c;进行自动化代码检查。它还提供了质量管理工具帮你主动纠正错误&＃xff1a;IDE 集成、Jenkins 集成和代码评审工具。

访问地址&＃xff1a;https://www.sonarqube.org

关键特性:

• 多语言支持&＃xff1b;
• 安全性分析&＃xff1b;
• 发布质量代码&＃xff1b;
• 可维护性&＃xff1b;
• 可以识别蹊跷的问题

引入集成测试等相关测试平台与Devops结合提升整体项目交付能力

六、疑问解答与加群交流学习