Gitlab Flow到容器（上）

一.简介

长话短说，本文全景呈现我司项目组gitlab flow && devops

Git Flow定义了一个项目发布的分支模型，为管理具有预定发布周期的大型项目提供了一个健壮的框架。 DevOps 强调的是团队通过自动化的工具协作和高效地沟通来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。开发关注代码，运维关注部署，效率和质量都能得到提升。

• 项目组10人小团队也在实践敏捷开发;
• 每个sprint周期一般包含2-3个功能;
• 采用前后端开发，生产均使用k8s部署;
• 每个sprint上线周期均经历 intergate Test—>alpha—>prod。

现代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标签名跟随迭代。