- 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 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环境，人工点击部署
- 使用ssh远程部署，请参阅
- 基于docker-compose完成的Gitlab-ci，请参阅
- 在kubernetes环境，我是使用kubectl set image ...命令改变镜像，同分支名更新则重新拉取部署。
