这篇文章主要介绍“Gitlab Flow与DevOps流程举例分析”,在日常操作中,相信很多人在Gitlab Flow与DevOps流程举例分析问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”Gitlab Flow与DevOps流程举例分析”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
创新互联专注于万州网站建设服务及定制,我们拥有丰富的企业做网站经验。 热诚为您提供万州营销型网站建设,万州网站制作、万州网页设计、万州网站官网定制、小程序制作服务,打造万州网络公司原创品牌,更为您提供万州网站排名全网营销落地服务。
操作
为在迭代便利性、部署严谨性上取得平衡,项目组(其实是我~。。~啦)设计了如下Gitlab flow & DevOps流程。
一个完整的迭代上线周期:
第①阶段:开发阶段
开发人员从develop切出feature分支,项目经理梳理本sprint需要上线的feature分支,自测完成后合并到develop; 此时会打出ImageTag:develop的镜像, 自动部署到集成测试环境,理论上还属于代码躁动的阶段; 开发人员应该关注集成测试环境,QA人员可酌情参与。
第②阶段:测试阶段
集成测试环境验证之后, 可从develop切出release-1.0.0预发布分支,此处会打出ImageTag:release-1.0.0的镜像, 自动部署到alpha环境; 此处QA会重点花时间在这个环境上测试, 发现问题,开发人员迅速响应; 从release-1.0.0分支上切出bugfix分支,修复完后迅速合并回release-1.0.0 分支,同样会自动部署到alpha,QA快速验证; ..... 这个阶段我们保持趋近一个稳定的release-1.0.0的分支。
第③阶段:部署阶段
从稳定的release-1.0.0分支打出对应的git tags: v1.0.0, 此处会打出ImageTag:v1.0.0的镜像,需要 手动部署到prod; QA线上测试,出现修复不的问题,迅速使用之前的ImageTag回滚; 上线之后若发现不能回退的bug,此时需要hotfix,还是从release-1.0.0切出hoxfix分支,修复完合并回release-1.0.0,alpha环境测试通过;打出git tags:v1.0.0-hotfix1 重新部署到prod; ..... 确认上线成功,将release-1.0.0分支合并回develop、master分支
这里为什么保留master分支, 是因为理论上当feature分支合并回develop分支,develop已经被污染了,这里保留master只为兜底。
后续就是开始新的sprint周期了,git release分支名/tag标签名跟随迭代。
Gitlab Flow小结
整个过程贯彻了git flow 预发布分支release,hotfix的核心用法, 同时在部署方式上也有一定的改进。
alpha上使用git预发布分支名release-1.0.0作为镜像Tag,切出release分支即形成同tag名镜像,自动部署 prod上要求从release分支上打出git标签,同时要求手动点击部署,多步骤操作确保部署是受控可预期,并且可回滚
作业小抄
集成测试采用docker-compose部署;alpha,prod是采用k8s部署;从上面的Gitlab flow 知道:
Git develop分支、release-分支、tag标签、master分支会打出容器镜像, Git develop分支代码(ImageTag:develop)(只)会自动部署集成测试环境, Git release- 分支(ImageTag:release-1.0.0)(只)会自动部署到alpha, Git tag标签(ImageTag:v1.0.0) 手动点击部署到prod
stages:
- build
- build_image
- deploy
variables:
deploy_path: "/home/eap/website"
build:
stage: build
script:
- pwd
- "for d in $(ls app/src);do echo $d;pro=$(pwd)/app/src/$d/$d.csproj; dotnet build $pro; done"
tags:
- my-tag
build_image:EAPWebsite:
stage: build_image
script:
- dotnet publish app/src/EAP.Web/EAP.Web.csproj -c release -o container/app/publish/
- docker build -t $DOCKER_REGISTRY_HOST/eap/website:$CI_COMMIT_REF_NAME container/app
- docker login $DOCKER_REGISTRY_HOST -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD
- docker push $DOCKER_REGISTRY_HOST/eap/website:$CI_COMMIT_REF_NAME
tags:
- my-tag
only:
- tags
- develop
- master
- /^release-.*$/i
deploy:intergate-test:
stage: deploy
script:
- ssh -t testUser@10.202.42.252 "cd /home/eap/website && export TAG=$CI_COMMIT_REF_NAME && docker-compose pull website && docker-compose -f docker-compose.yml up -d"
tags:
- my-tag
only:
- develop # 开发阶段,intergate Test环境只会部署ImageTag:develop镜像
deploy:alpha:
stage: deploy
script:
- ssh -t testUser@10.201.82.170 "sudo kubectl set image deployment/eap-website eap-website=repository.****.com:8443/eap/website:${CI_COMMIT_REF_NAME} && sudo kubectl rollout status deployment/eap-website"
tags:
- my-tag
only:
- /^release-.*$/i # alpha环境只部署以ImageTag:release-开头镜像
deploy:prod:
stage: deploy
script:
- ssh -t testUser@10.202.42.20 "sudo kubectl set image deployment/eap-website eap-website=repository.****.com:8443/eap/website:${CI_COMMIT_REF_NAME} && sudo kubectl rollout status deployment/eap-website"
tags:
- my-tag
only:
- tags
- master
when: manual # prod环境,人工点击部署
到此,关于“Gitlab Flow与DevOps流程举例分析”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注创新互联网站,小编会继续努力为大家带来更多实用的文章!
本文题目:GitlabFlow与DevOps流程举例分析
文章起源:http://lswzjz.com/article/pepscs.html