操作

為在迭代便利性、部署嚴謹性上取得平衡，項目組(其實是我~。。~啦)設計了如下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環境，人工點擊部署