单应用与环境
多应用与环境
CI持续集成
首先，准备一个代码库：
我们来梳理一下CI流水线的步骤：
由于此次实现的代码仓库类型为单一存储库，即一个存储库存放多个服务模块代码，每个子目录为一个服务模块。 首先，我们的持续集成流水线需要能够正确获取，当前的commit是哪个服务的代码。 确定好服务，然后下载该服务的代码，进行编译打包、单元测试、代码扫描和构建镜像等步骤。
如何获取commit的服务信息?这里我们使用GitLab WebHook功能和Jenkins 的job 构建触发器对接来实现。
工作流程是：当我在Gitlab提交了代码，会通过GitLab webhook 触发Jenkins Scheduler 作业， 会将此次提交代码所产生的hook data数据信息以POST的方式传给Jenkins Job。此时Jenkins job可以编写使用Generic Hook插件获取此次POST请求传输过来的请求体Body信息。是一段JSON数据， 该job运行后编写Pipeline 解析JSON中的数据拿到所变更的服务模块信息。最后触发对应服务的CI作业进行构建。
CI-Scheduler 作业
CI流水线-CI作业
每个微服务创建一个CI作业，具有三个字符串参数：分支名称、commitID、项目ID。
在原始CI作业的步骤基础上，增加了一个更新环境的步骤。GitOps实践会将当前的基础环境部署文件存放到一个Git仓库中。我们的CI作业在完成镜像上传后，同时更新环境部署文件中的镜像标签信息。(所以我们需要先获取该环境文件并更新上传)
images
GitOps-CD部分
CD-Scheduler作业
Jenkinsfile pipelineagentanystagesstage('GetCommitService')stepsscriptecho'HelloWorld'echo"$WebHookData"//GitInfowebhookdata=readJSONtext:"""$WebHookData"""eventType=webhookdata["object_kind"]commits=webhookdata["commits"]branchName=webhookdata["ref"]-"refs/heads/"projectID=webhookdata["project_id"]commitID=webhookdata["checkout_sha"]changeServices=[]for(commitincommits)println(commit.id)//addedfor(addincommit.added)s=add.split("/")asListif(s.size()gt;1)if(changeServices.indexOf(s[0])-1)changeServices.add(s[0])//modifiedfor(mincommit.modified)s=m.split("/")asList//printlns//printlns.size()//printlns[0]if(s.size()gt;1)//printlnchangeServices.indexOf(s[0])if(changeServices.indexOf(s[0])-1)changeServices.add(s[0])//removedfor(rincommit.removed)s=r.split("/")asListprintlnsif(s.size()gt;1)if(changeServices.indexOf(s[0])-1)changeServices.add(s[0])println(changeServices)currentBuild.description="Triggerby$eventType$changeServices"stage('DefineService')stepsscriptprintln(changeServices)//服务构建顺序控制services=['service02','service01']for(serviceinservices)if(changeServices.indexOf(service)!=-1)jobName='microservicecicd-'+service+'-service-CD'buildjob:jobName,wait:false,parameters:[string(name:'branchName',value:"$branchName")] 环境库配置webhook
CD流水线-CD作业
