大揭秘| 我司项目组Gitlab Flow && DevOps流程

简介: 长话短说,本文全景呈现我司项目组gitlab flow && devops
  • Git Flow定义了一个项目发布的分支模型,为管理具有预定发布周期的大型项目提供了一个健壮的框架。


  • DevOps 强调的是团队通过自动化的工具协作和高效地沟通来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件。开发关注代码,运维关注部署,效率和质量都能得到提升。


  • 项目组10人小团队也在实践敏捷开发;


  • 每个sprint周期一般包含2-3个功能;


  • 采用前后端开发,生产均使用k8s部署;


  • 每个sprint上线周期均经历 intergate Test--->alpha--->prod。


现代Devops技术基于容器技术自动化脚本实现了依赖环境的打包、版本管理、敏捷部署。


我司操作


为在迭代便利性、部署严谨性上取得平衡,项目组(其实是~。。~啦)设计了如下Gitlab flow & DevOps流程。


fdd86bd286d4e8bdb912ead8ea5ebe30.png


一个完整的迭代上线周期:


第①阶段:开发阶段


  • 开发人员从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只为兜底。


2ba74c8ba806f18e8d16c2d8accfc17c.png

db2ea751988ff7bb0c25a29257107746.png

5ba6ee26a69d5cf77e04a1b119b37b70.png


后续就是开始新的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 restart 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环境,人工点击部署


  1. 使用ssh远程部署,请参阅

  1. 基于docker-compose完成的Gitlab-ci,请参阅

  1. 在kubernetes环境,我是使用kubectl set image ...命令改变镜像,同分支名更新则重新拉取部署。

相关文章
|
Devops 开发工具 git
【devops】二、Code阶段工具——容器部署Gitlab
【devops】二、Code阶段工具——容器部署Gitlab
124 0
|
6天前
|
运维 Devops 测试技术
自动化运维的魔法——打造高效的DevOps流程
【10月更文挑战第28天】在数字化浪潮不断推进的今天,企业对运维效率的追求如同古人探索魔法一般充满好奇与渴望。本文将带你走进自动化运维的世界,揭秘如何通过DevOps实践,实现从代码到部署的无缝连接,提升企业的IT运营效能。我们将一起探索自动化工具的选择与配置,以及如何构建一个既能快速响应业务需求,又能保障系统稳定性的高效流程。
|
11天前
|
监控 Devops jenkins
自动化部署与监控:打造高效的DevOps流程
【10月更文挑战第24天】在追求快速迭代和持续交付的软件开发时代,DevOps成为提升团队效率的关键。本文深入探讨如何构建一个高效的DevOps流程,包括自动化部署、监控和故障排除等关键环节。通过实际案例,我们将学习如何利用工具简化运维任务,确保系统稳定运行,并快速响应生产问题。
26 2
|
5月前
|
运维 Java Devops
阿里云云效操作报错合集之在进行GitLab代码分支迁移时遇到报错,一般是什么原因
本合集将整理呈现用户在使用过程中遇到的报错及其对应的解决办法,包括但不限于账户权限设置错误、项目配置不正确、代码提交冲突、构建任务执行失败、测试环境异常、需求流转阻塞等问题。阿里云云效是一站式企业级研发协同和DevOps平台,为企业提供从需求规划、开发、测试、发布到运维、运营的全流程端到端服务和工具支撑,致力于提升企业的研发效能和创新能力。
|
23天前
|
缓存 监控 数据可视化
利用GitLab CI/CD自动化您的软件开发流程
【10月更文挑战第10天】GitLab CI/CD 是 GitLab 内置的持续集成和持续部署工具,通过编写 .gitlab-ci.yml 文件,可以自动化构建、测试和部署应用程序的过程。本文介绍 GitLab CI/CD 的核心优势、实施步骤及在现代开发中的应用,帮助您提高开发效率和软件质量。
|
3月前
|
持续交付 jenkins Devops
WPF与DevOps的完美邂逅:从Jenkins配置到自动化部署,全流程解析持续集成与持续交付的最佳实践
【8月更文挑战第31天】WPF与DevOps的结合开启了软件生命周期管理的新篇章。通过Jenkins等CI/CD工具,实现从代码提交到自动构建、测试及部署的全流程自动化。本文详细介绍了如何配置Jenkins来管理WPF项目的构建任务,确保每次代码提交都能触发自动化流程,提升开发效率和代码质量。这一方法不仅简化了开发流程,还加强了团队协作,是WPF开发者拥抱DevOps文化的理想指南。
77 1
|
6月前
|
存储 网络安全 数据安全/隐私保护
docker 安装gitlab,配置邮件,备份全流程
docker 安装gitlab,配置邮件,备份全流程
241 0
|
2月前
|
运维 监控 Devops
DevOps实践:构建高效运维流程
【9月更文挑战第3天】在当今快节奏的技术环境中,高效的运维流程是企业成功的关键。本文旨在揭示如何通过DevOps实践,构建一个既灵活又高效的运维体系。我们将深入探讨自动化工具、持续集成与持续部署(CI/CD)策略以及监控和日志管理的最佳实践,以实现运维工作的优化。文章将用简洁明了的语言,结合生动的比喻,带领读者走进DevOps的世界,学习如何将理论应用到实际工作中去。
|
3月前
|
持续交付 jenkins C#
“WPF与DevOps深度融合:从Jenkins配置到自动化部署全流程解析,助你实现持续集成与持续交付的无缝衔接”
【8月更文挑战第31天】本文详细介绍如何在Windows Presentation Foundation(WPF)项目中应用DevOps实践,实现自动化部署与持续集成。通过具体代码示例和步骤指导,介绍选择Jenkins作为CI/CD工具,结合Git进行源码管理,配置构建任务、触发器、环境、构建步骤、测试及部署等环节,显著提升开发效率和代码质量。
72 0
|
4月前
|
运维 监控 Devops
DevOps实践:构建高效运维流程
【7月更文挑战第23天】在当今快速发展的信息技术时代,DevOps作为一种文化和实践,正在彻底改变软件开发和运维的方式。本文将深入探讨如何通过实施DevOps原则和工具来构建高效的运维流程,旨在帮助读者理解DevOps的核心概念、实施步骤以及面临的挑战,并提供实用的解决方案和最佳实践。文章将重点介绍自动化部署、持续集成、监控和反馈机制等关键要素,以促进团队协作,提升软件交付速度和质量。