江狐会｜研发管理DevOps最佳实践之三问三答

近日，极狐(Gitlab)江狐会·北京站在极狐北京 Demo Center 如期开展。

会上，极狐(Gitlab)高级解决方案架构师杨周带来了《研发管理 DevOps 最佳实践》主题分享，解答了如下备受关注的问题：

Git Flow 过时之后推荐用什么？

Java/VUE 老项目如何落地代码规范？

为什么不该用 CI 做部署，而是 CD、GitOps？

希望给普遍面临这些问题的开发人员尤其是研发负责人、架构师，以及开源和 DevOps 的爱好者们提供一些参考。

以下内容整理自本次分享，enjoy～

Git Flow 过时了，那应该用什么呢？

Git Flow 是一种诞生于 2010 年的工作流，一篇名为《一个成功的 Git 分支模型》的文章将 Git Flow 推入了开发团队的视野。但在 2020 年，其作者 Vincent Driessen 宣布 Git Flow 不适合「持续交付」。

原因是 Git Flow 适合当年多版本共存的软件，而现代软件大部分只有「最新版」，比如网站打开永远是「最新版」、App 会提示升级而不会维护旧版本。所以 Git Flow 的发布分支（如 release/1.2.0）和支持分支（如 support/1.x）不再常用。

那么问题来了：Git Flow 过时了，我们应该用什么呢？

现在业界常用的 Git Workflow 有「简易 Git Flow」、「GitHub Flow」、「GitLab Flow」，个人总结它们的特点如下，大家可应需选用。

• 简易 Git Flow：保留 Git Flow 的双长期分支（main 和 develop）、几个临时分支（feature/xxx、bugfix/xxx、hotfix/xxx），而舍弃 release 和 support；
• GitHub Flow：非常简单，拉取临时分支，合并到主干即可；适合人少的小项目，比如个人开源项目；
• GitLab Flow：包括多种 Flow，比如 「Production branch with GitLab Flow」、「Environment branches with GitLab Flow」、「Release branches with GitLab Flow」。

Java/VUE 老项目如何落地代码规范？

如何做一名优秀的研发工程师？从改善每一行代码开始。若有《程序猿的自我修养》，缩进、换行、大小写、注释，应该大写加粗印在扉页上。😄

图片来源：电影《喜剧之王》

而经验告诉我们，规范写在纸上或者口头传达依然不尽人意，因此，强制自动执行的自动检查代码规范（lint）出圈了。业界知名的代码规范都有配套的 lint，比如 VUE 用 eslint，Java 用 checkstyle。新项目可以直接扫描整个目录，把检查命令放在 CI 里，即可实现在代码合并请求时强制检查规范。比如：

• VUE 项目执行 npm run lint
• Java 项目执行 ./gradlew check

但是，如果老项目的规范报错太多，就需要所有人暂停手头工作，一起清理。这样做的成本太高了，哒咩🙅，所以很多老项目只能越来越差。

新的解决方案是采用增量扫描，即只扫描本次修改的文件。这样，随着时间的推移，只要老项目还在维护，代码就会越来越干净漂亮。

为什么不要用 CI 做部署，而是用 CD、GitOps？

CI （Continuous Integration）和 CD（Continuous Deployment） 都是自动化流水线，但 CD 更适合部署。区别在于：

1. CI 基于代码，而 CD 基于包。当需要回滚时，CI 必须重新编译打包，可能很久，而 CD 瞬间获取上一个版本的包，降低了「故障恢复时间」。
2. CI 难以区分多个环境，而 CD 具有多环境配置管理，比如 testing、staging、production。
3. CI 没有上线审批，而 CD 有，可以为每个环境设置审批人。

但 CD 仍然有缺点，即因为它缺少基础设施的完整信息（比如 K8s yaml），在灾难恢复、为客户私有化部署时，无法瞬间创建新环境。

GitOps 解决了 CD 的这个缺点，实现了：

1. 基础设施即代码（IaC）：Git 作为单一可信源，保存完整的基础架构信息，可实现快速部署新环境（灾难恢复、销售私有化产品）。
2. 合并请求（MRs）：借助 Git 的合并请求评审机制，让部署可评审、记录可追溯。
3. 更安全：由于 Git 中保存了完整的基础设施配置，可通过 Agent 拉取生效，而不像 CD 流水线推送需要暴露服务器网络权限。

极狐 GitLab 同时支持 CI、CD、GitOps，建议大家使用 CD 和 GitOps 进行部署。