1. 程式人生 > 實用技巧 >大揭祕| 我司專案組Gitlab Flow && DevOps流程

大揭祕| 我司專案組Gitlab Flow && DevOps流程

長話短說,本文全景呈現我司專案組gitlab flow && devops

  • Git Flow定義了一個專案釋出的分支模型,為管理具有預定釋出週期的大型專案提供了一個健壯的框架。
  • DevOps 強調的是團隊通過自動化的工具協作和高效地溝通來完成軟體的生命週期管理,從而更快、更頻繁地交付更穩定的軟體。開發關注程式碼,運維關注部署,效率和質量都能得到提升。
  • 專案組10人小團隊也在實踐敏捷開發;
  • 每個sprint週期一般包含2-3個功能;
  • 採用前後端開發,生產均使用k8s部署;
  • 每個sprint上線週期均經歷 intergate Test--->alpha--->prod。

現代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 [email protected] "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 [email protected] "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 [email protected] "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遠端部署,請參閱 https://www.cnblogs.com/JulianHuang/p/13374066.html
  2. 基於docoer-compose完成的Gitlab-ci,請參閱 https://www.cnblogs.com/JulianHuang/p/11346615.html
  3. 在kubernetes環境,我是使用kubectl set image ...命令改變映象