• 深入剖析代码管理的那些事
  • 发布于 2个月前
  • 201 热度
    0 评论
做为一名测试,对代码管理多少会有些了解。比如当我们测试一个新功能的时候,研发会说:“你在某某分支上验证”,还有当我们需要集成包的时候,研发也会说:“等我把代码合并一下”。这里的“分支”和“合并”,都是代码管理中的常用词。

那为什么需要代码分支?代码合并又是合到哪里?最后发布用的是什么?紧急缺陷要怎么处理?所有这些问题的背后,其实都有着质量方面的考量。今天作者就从测试的角度,来深入剖析下代码管理的那些事。我们不妨重头开始,逐步构建出一个庞大的代码帝国。

Git 是当前比较流行的版本管理工具,接下来主要还是基于它来进行解读(SVN 可类推)。Git 的默认分支是 Master,现在假设不再需要其他分支,所有团队成员直接在 Master 上提交自己的代码,我们一起来看看到底会发生什么。

由于 Master 随时可能会有新的代码合入,一来会导致彼此之间相互影响,测试过程频繁被阻断;二来当前的测试结果会被破坏,可靠性无法得到保证。也就是说,质量上的成本和风险均会成倍增长,这显然不是一个明智的做法。

有人会采用一种变通的办法:指定某段时间不允许提交代码,只专注于测试,待验证通过之后再进行部署。这种做法也存在一定风险,倘若需要紧急发布(比如严重缺陷修复),因为只有一个分支,就不得不连同未经测试的代码一起部署。

单分支模式还有一个隐患是,万一其中部分代码出现问题(比如临时砍掉某个需求),由于所有代码都合到了一起,我们无法针对特定代码进行隔离和回滚,需要付出很大代价才能完整移除新增代码。

正因为这种种不便,所以单分支模式几乎不会出现在实际的团队协作场景中。

即然不能在 Master 上完成所有代码活动,很自然的,我们就会想到利用多分支的方式进行管控。当我们需要变更代码的时候(不论 feature 或 hotfix),都从 Master 上创建一个新的分支进行开发,待测试通过之后再合并回 Master 进行部署。

这种代码管理方式比较简明(相对后续要讲的 Git flow),适合有快速迭代诉求的持续集成模式,是 Github 较为推荐的做法,所以也叫 Github flow。(需要说明的是,任何模式都只是一种建议,而不是一种规定。)

相对于单 Master 分支的模式,Github flow 提供了稳定的分支测试环境,能够保证充分的分支测试时长,并且当分支出现问题时,即不会阻塞其他分支,也不用考虑回滚。然而即便有着这些优点,但它对质量保障的能力要求却很高。

由于 Master 是个随时可以发布的分支,并且合并的频率相对比较高,所以可用于集成测试的时间窗口很短。我们必须拥有通过单测及其他自动化手段,进行快速、全面的回归验证的能力,否则测试很容易被这种连续高频的变更拖垮。

对于没那么“精悍”的团队,我们需要一种兼顾分支和集成的方式。

沿着这个思路,为了保持 Master 的稳定,我们又建立了一个 Develop 分支,用来承担集成测试的责任。新的功能分支从 Develop 分支创建,紧急修复分支从 Master 分支创建,集成测试环境则基于 Develop 分支来部署。

因为 Develop 不作为生产部署的分支,所以我们可以一直在它之上进行充分的测试,直至认为达到了发布的标准,即可将 Develop 分支合入 Master,而后基于 Master 分支完成生产环境的部署。

这里面还有一个问题是,Develop 分支仍然会面临随时都有新代码合入的局面,虽然它不会影响生产环境的部署,但是这种不确定性仍然会导致集成测试的结果不稳定(参考单 Master 分支的问题)。

为了解决这个问题,我们可以制定一个机制,在集成测试的时间段内,禁止新的分支合入 Develop(因为 Hotfix 是从 Master 创建的,所以不用担心紧急修复的情况),待集成测试通过并且合入 Master 之后,再重新开放合并操作。

直至为止我们已经做得挺好的了,那么还有没有优化的空间呢?

虽然我们可以通过控制 Develop 的合并时间窗口,来保证集成测试环节的稳定,但这种做法其实很不“敏捷”。因为在非窗口期,所有就绪的分支都只能原地等待,集成过程中(比如代码冲突、关联影响)可能发生的问题,均不能及时暴露出来。

为此我们可以进一步对分支进行分化,从 Develop 分支生成一个 Release 分支,Develop 分支用于持续集成,而 Release 分支用于集成测试。如此一来,完成的分支就可以随时往 Develop 上合并,也不用担心影响集成测试的稳定。最后得到的这张图,其实就是 Git flow。前面我们通过逐步推导的方式,来了解为什么它要这么设计。

虽然 Git flow 很有名气,但它确实比较复杂,所以很多团队也并未完全遵循这套模式,而是引入一些自己的特点。其他比较常见的模式除了前面提到过的 Github flow,还有一种 Gitlab flow,它是介于 Git flow 和 Github flow 之间的一个方案。

Gitlab flow 的特点是“上游优先”,即将开发环境、集成环境、生产环境(前者都是后者的上游)分别创建一个分支来对应,只有上游通过的内容,才能合并到下游做进一步的测试。

Git flow、Gitlab flow、Github flow 三者之间的复杂度从高到低,质量保障的能力要求从低到高。它们各自适用于不同的情况,没有绝对的好坏,也不是既定的标准。正因为代码的管理方式和质量保障有很大的关联性,所以我们需要去了解这些代码管理模式的区别,以便确定不同的质量流程和策略,达到最好的保障效果。
用户评论