2021/01/22 基于sharedLibrary进行CICD流程的优化(二)

最新推荐文章于 2024-05-22 22:12:01 发布

48N6E

最新推荐文章于 2024-05-22 22:12:01 发布

阅读量354

点赞数

分类专栏： K8S进阶

本文链接：https://blog.csdn.net/qq_42227818/article/details/112908443

版权

K8S进阶专栏收录该内容

32 篇文章 20 订阅

订阅专栏

第8章集成robot自动化测试

8.1 配置robot-cases项目自动化

单元测试是开发写的

在这里插入图片描述
通常是调用api

在这里插入图片描述
上面的测试用例是测试人员写的

新开发版本对之前的版本有没有影响

在这里插入图片描述

写两个流水线，从1个流水线调用另外一个流水线

在这里插入图片描述

初始化项目的目录

在这里插入图片描述
提交一下

这样就放到了gitlab上

在这里插入图片描述

新建jenkinsfile，可以给一个参数，然后去运行哪个项目的测试用例

env.comp，从环境变量了读取comp参数，comp是component组件的意思
在这里插入图片描述

新建一个jenkins流水线

在这里插入图片描述

参数化构建就是要在构建的时候传递参数

在这里插入图片描述

这里就会有一个参数

在这里插入图片描述

开始构建

在这里插入图片描述
还是用了jnlp

在这里插入图片描述
这里就会有jnlp的pod

在这里插入图片描述

这里完成了

在这里插入图片描述
都是ok的

在这里插入图片描述

8.2 library实现验收测试任务触发

robot-cases说明已经是可以成功运行的项目了

在这里插入图片描述

部署了myblog服务想要去检测集成用例是否OK
比如下面两个项目都需要测试，就是公共需求
在这里插入图片描述
公共需求可以用library去做，可以在sharelibrary去实现触发任务的执行

comp就是这里需要接收的参数

在这里插入图片描述

导入一下robot

在这里插入图片描述

加到jenkinsfile里

在这里插入图片描述

提交一下

到达deploy的时候会执行集成测试

在这里插入图片描述
触发测试

在这里插入图片描述
由上游项目触发

在这里插入图片描述

这样就可以在myblog项目里，可以去掉library里的内容

第9章多环境CICD流程实践

9.1 多环境CICD实现目标及效果

在这里插入图片描述
这里的jenkinsfile需要改一下

在这里插入图片描述
library改一下名字

在这里插入图片描述
现在涉及到的都是单分支单环境

在这里插入图片描述

这是提交git的commitid

develop分支其实可以去和开发环境做绑定
、
开发人员发布develop分支后，自测没有问题合并到master，想要发版，打一tag，就不是commitid了，K8S部署后，有一个集成测试环境，测试人员可以在这个环境进行测试
在这里插入图片描述

9.2 Jenkinsfile根据分支选择任务

在这里插入图片描述

只有一个K8S集群，myblog部署到luffy名称空间，要想区分环境，还需要新建名称空间

在这里插入图片描述

develop分支部署到开发环境，master分支部署的时候执行测试

在这里插入图片描述
可以使用不同的jenkinsfile，但是使用可行性很差，因为有代码合并的工作

在这里插入图片描述
对jenkinsfile还是一套，改进library，让library根据不同的分支，做改进

~正则表达式
、在这里插入图片描述
任务里选分支

在这里插入图片描述
在develop分支里执行

在这里插入图片描述

jenkinfile拿到master上，点击回放
在这里插入图片描述

在这里插入图片描述
这个阶段被跳过了

在这里插入图片描述

需要在job的配置里先匹配到

在这里插入图片描述
这两个通过library去实现

在这里插入图片描述

9.3 模板化k8s资源清单

在这里插入图片描述
这里只有一个deployment文件

在这里插入图片描述
但是还有其他的，ingress，svc，secret，configmap、这些都是手动准备好的，所以没有去写

在这里插入图片描述

在这里插入图片描述

ingress只需要这些关键的

在这里插入图片描述
dev想要发布到dev名称空间，tag想要发布到tag名称空间

在这里插入图片描述
需要模板化的内容，镜像地址，命名空间，ingress域名信息

在这里插入图片描述
可以在library里做模板化

*ingress域名也需要模板化
*

在这里插入图片描述 、还有service也拿过来

在这里插入图片描述

在这里插入图片描述
configmap

secret

这样就可以把所有资源清单文件都创建好

在这里插入图片描述

在这里插入图片描述

下一步实现library的替换

在这里插入图片描述

9.4 实现library模板替换

在这里插入图片描述
第一步实现test，dev

tag就是比如要发版的时候可以打一个tag
在这里插入图片描述

在这里插入图片描述
上面这段代码在master里执行一下

在这里插入图片描述
这里就扫描到之前打tag的标签

在这里插入图片描述
立即构建

在这里插入图片描述
tag分支执行

在这里插入图片描述
这里的tagname就有值了

在这里插入图片描述

这样就可以通过tagname知道，是标签触发，还是分支触发的构建，标签触发的构建会多一个tagna’me，分支触发的不会有tagname

原有的sed改成调用函数

默认名称空间是dev

如果是tag标签发布的就发布到test

在这里插入图片描述

目前只实现了dev和test名称空间，后面可能有集成测试，其他项目组如果都需要CICD的流程，下面的tplHandler项目就还需要去修改

每个环境对应的configmap不一样
约定configmap里key的值

在这里插入图片描述

上面的值是要替换yaml文件里的值
在这里插入图片描述
这样写好，library就不用修改，只需要修改configmap就行

也就是每个命名空间里维护一个configmap，名字是固定的，devops-config，对tplhandler进行修改

在这里插入图片描述
getresource是去拿同一名称空间下的。一个资源类型的值读出来，就是读json文件，返回json对象

要去读configmap里的data值

应该是这样。groovy里不支持for循环

在这里插入图片描述

9.5 准备开发和测试环境

在这里插入图片描述

luffy这个名称空间先删除，pod都先置0

在这里插入图片描述

在这里插入图片描述
mysql在dev名称空间里已经启动了

在这里插入图片描述
这里换成test就直接是在test名称空间下创建mysql了

在这里插入图片描述

在test环境里再创建

准备开发环境下的文件
在这里插入图片描述

创建configmap

同时再测试环境也要做一次相同的操作

这里问的条件变量，直接修改即可

在这里插入图片描述
有新文件添加后，要执行add

develop会部署到开发环境

在这里插入图片描述

9.6 验证多环境自动部署

在这里插入图片描述
这里已经再构建了，只要develop代码提交就开始构建部署到dev环境

在这里插入图片描述

这里没有做migrate，所以不是1

在这里插入图片描述

这里就变成1了

在这里插入图片描述
在library里去读了devops-config这个值，读完循环去替换

循环做替换

替换image，然后getresource

在这里插入图片描述
develop分支跳过了测试

在这里插入图片描述

开发环境好了，提交代码到develop分支会部署到develop分支上

merge一下

不要把source删掉

不想让master显示

这里只要显示develop或者v.*

develop的分支做了改动都到这里了

在这里插入图片描述
多个人开发了想要发布，打一个tag

在这里插入图片描述

和master代码一致

在这里插入图片描述
想要自动触发，但是没有实现

在这里插入图片描述

9.7 实现打标签后自动部署

可以识别tag，但是不能自动部署
在这里插入图片描述

安装这个插件

在这里插入图片描述
装了插件就有了新的一行

在这里插入图片描述
普通的分支都可以通过

在这里插入图片描述
忽略一天内的tag，tag超过7天了也忽略

在这里插入图片描述

7天以后的tag就看不到了

在这里插入图片描述

tag触发了一次执行

在这里插入图片描述

在这里插入图片描述

先把表初始化好

在这里插入图片描述
已经在running了

在这里插入图片描述

做了一个test

在这里插入图片描述
test是可以访问到的

在这里插入图片描述

9.8 优化镜像tag逻辑

dev分支是可以拿到commit id，其实tag分支没有做处理，没有commitid
在这里插入图片描述

在去做build的时候，传递了git commit

在这里插入图片描述
判断是否是tag分支

在这里插入图片描述
如果是tag分支，就赋值

在这里插入图片描述

打一个tag

在这里插入图片描述

开始构建

在这里插入图片描述
这里修改的

在这里插入图片描述
tag就更新上去

在这里插入图片描述
现在推到develop分支

在这里插入图片描述
dev分支就检测到了，去运行

在这里插入图片描述

sornar检测失败，重复代码太多了

在这里插入图片描述
把这个苛刻的要求删掉

在这里插入图片描述
再去构建

在这里插入图片描述
起了个新的

在这里插入图片描述
访问开发环境

在这里插入图片描述
已经优化完成了

在这里插入图片描述

第10章本章小结

10.1 本章小结

在这里插入图片描述

看一下旧版的library，很多写死的，现在就没有

在这里插入图片描述

推到码云上了

在这里插入图片描述

项目里定义的全是模板，deploy全是模板，只要是环境绑定的都替换成了模板，数据是定义的devops_configmap，sharelibrary去实现对模板的替换

在这里插入图片描述

48N6E

关注

0
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
2021/01/22 基于sharedLibrary进行CICD流程的优化(二)

消息通知第7章 library集成代码扫描7.1 library集成代码扫描直接去执行代码扫描，等待3秒返回结果检测的时候有一个version概念有时候可以不等待检测结果，可以给一个开关现在去建立sonar的类这样就拿到version，commitid这样就实现动态version变化是否需要等待，然后成功或者失败没有找到scan提交一下提交一下不想检测就false，前面的空值会自动帮你获取version对应上面的version这里少了一
复制链接

扫一扫