实践者的 DevOps 之路(2. 迈出第一步: 分支模型)

DevOps 不仅涵盖了从开发，部署，线上监控的多个环节，还包括了组织文化，工作流程的变化，因此许多人在开始实施 DevOps 时往往觉得无从入手，或是匆忙之中采取了一些反模式，最终导致 DevOps 没有起到预期的效果。

那么该如何开始一个 DevOps 项目呢？或是如何启动组织内的 DevOps 实践呢？本文会从整个 DevOps 流程的第一步，分支模型开始，讲述如果落地 DevOps。

选择适当的分支模型

作为整个 DevOps 的开始，你的开发分支模型是非常重要的，与你的发布计划与频率息息相关。在主流的实践中有以下的几种选择，我会基于自己的经验分享各种不同模型的长处与缺陷。

基于主干开发的分支模型

它的优点是简单易用，如果你的团队不大，整个团队单纯负责一款产品的开发，那么你可以尝试这种分支模型。

整个流程很简单，master 即主干分支，它对应的是随时可以发布上线的稳定版本，任何开发人员都不应该直接在这条分支上提交代码。

Dev 即开发分支，所有的开发人员都在这条分支上工作，提交代码。hotfix 分支对应的是缺陷修复分支，对应 master 版本上发现缺陷需要修改的分支。

整体的工作流程如下图所示：

从上图稍做修改之后就会发现，这种模型需要固定频率的合并代码与发布。假设你的团队是采用例如 Scrum 这种敏捷的工作方式，每个迭代(1 周或是 2 周)发布一次，那么此时 dev 代码会自动合并到 master 分支。master 分支的代码经过自动化测试，回归测试等，就可以认为是 production ready 状态了。

对于开发人员的要求则是要有良好的开发习惯，最好是 TDD 的拥趸，在开发一段代码，通过 UT 后，就提交到 dev 分支，而不是开发了3，4 天之后才提交，从而避免不必要的代码冲突。

当你的系统是个大型的单体应用，你的团队人数众多，又分为数个小团队，每个小团队开发各自不同的 feature，那么这种模型的缺陷就很明显。

首先如果系统各个模块的边界不是那么清晰，隔离做的不好，那么团队提交的代码很可能频繁的冲突或是破坏集成测试，造成团队开发效率的降低。

其次固定频率发布的优点是有计划，可预期发布的功能，而随之带来的无法灵活的响应需求做到完成某个功能即上线。同时在一些大型团队，发布的频率无法做到 2 周一次，往往是 1 个月一次，这会让这种模式的缺陷愈加严重。

如果你的团队规模不大(5 ~ 10)，开发的则是一款中小型的应用，那么我建议你采用基于主干开发的分支模型，快速，简单，易于上手。

GitFlow

GitFlow 是由 Vincent Driessen 提出的一种 Git 分支模型，网上的讨论很多，下面的图片来自作者的文章。

网上对于 GitFlow 的讨论已经很多了，你可以在以下的连接获得更加详细的信息与工具。

git-flow 备忘清单

https://danielkummer.github.io/git-flow-cheatsheet/index.zh_CN.html

在实践中大家对于 GitFlow 的诟病之处主要在于两点，其一是工作流程稍显复杂，需要对开发人员做一定的培训。其二是如果 feature 划分不合理，出现需要开发很长周期的 feature 时，合并回 dev 分支所遇到的冲突问题会很明显。

有部分开发人员的观点是，除了主干分支之外，不应该长时间的存在一个公用分支，这会造成分支合并时需要额外的时间解决代码冲突。从精益的角度而言这是一种浪费。应该频繁的提交到主干版本，通过 CI 来保证主干的稳定性。

从我的角度而言，GitFlow 在某些项目上表现的很好，但是在另一些项目上可能就存在不少的问题。但是仔细分析，这往往与 GitFlow 没有什么太大的关系，而是整个团队的迭代节奏，工具的熟练程度，以及 feature 到 user story 的拆分。如果你的团队规模在 10 人以上，对 git 的使用很有经验，并且按照类似 Scrum 的流程运转的很流畅，那么我建议你可以考虑使用 GitFlow 的分支模型。

GithubFlow

从名字上可以看出，这是由 Github 提出的一种分支管理模型。下面的图展示了工作的流程，你会发现整个流程与基于主干的模型非常类似，只保留一条 master 主干分支，任何一个 feature 的开发都会新建一条分支。但是在合并的过程中，GithubFlow 是依靠 PR(Pull Request)，由主干的维护者 code review 之后再合并的。

GithubFlow 的优点也是在于简单，基于 feature 开发。但是它严重依赖于团队有健全的 code review 机制，项目需要专门留出 code review，PR 审核的时间。之前参与过的项目中有很多 PR 的审核流于形式，往往较为宽松，只要没有冲突就直接通过，对整个项目的代码质量造成了很大的伤害。

反思

上面 3 种是我在之前项目中使用过的分支模型，在我做项目回顾时发现，其实并不存在一种完美的分支模型，只有适合你团队的分支模型。但是所有这些模型的目标都只有一个，就是一定要有一条时时刻刻 production ready 的分支。同样的任何一个分支模型都需要团队在其他方面最佳实践的支撑，例如规划迭代，单元测试，user story 编写， code review 等，具体可参考下图。

所以这也是我在文章的一开头就提及的，DevOps 是一个系统性，全局的实践，其中的分支模型亦是如此。当你觉得你的分支管理十分混乱，每次发布前在代码集成层面麻烦不断时，不然先看一下其他相关方面的实践做的好不好，而不是草率的换一种分支模型，这往往会暂时解决一个老问题，又引入一个新问题。

最后，我的建议是，如果你的团队规模不大，产品也较为简单，可以从基于主干的分支模型开始。如果你的团队已经在使用例如 Bitbucket，GitLab 等支持 PR 的工具，那么我觉得你不妨使用 GithubFlow，培养团队内部 code review 的习惯。知道团队达到一定规模时，再尝试 GitFlow。

下一篇我会介绍 DevOps 中的 CI/CD，希望你不要错过！

相关阅读：

面对疫情这样的复杂问题，有什么招呢？

疫情中的员工关怀，我只服这家公司

DevOps关键能力之产品和流程 - 重磅新书预览《加速》

小说体敏捷/DevOps转型教科书

和实战经验分享

购书指南

—

纸质书、电子书在京东、当当、亚马逊、微信读书等渠道已全面上架，搜索关键字“猎豹 敏捷”即可找到。点击阅读原文可直接购书。

有声书已登录喜马拉雅、微信读书，适合路上听书的你。

关注公众号看其他原创作品

敏于思 捷于行 

坚持每周输出一篇高质量文章

觉得好看，点个“在看”或转发给朋友们，欢迎你留言