最近我们因为一个问题需要加班到半夜。

因为我们的主干代码里有一个严重的问题，需要紧急修复，这个bug发现的时间很精妙，在发布的前一天夜里。

那一夜，基本上所有的需求都开发完成了，处于测试状态中，那么如何去修改这个严重的bug呢？开发说就在主干上改，改完以后测试同学顺便加班把其他需求都测完，我们提前一天在半夜强行发布。

于是测试同学便需要加班到半夜，那天我不在，不知道他们有没有留下没有技术的泪水。

其实紧急问题没有必要合在常规版本里强行发布。

一般的做法是在当前生产的分支修复问题，然后把生产分支合回主干。

但我们的情况没有这么幸运，我们直接在master分支上开发，生产的代码也是master的，这就导致了用单一主干去承载开发，测试和发布3种主要用途，风险很高。

比如一旦生产有问题，那么就必须去回忆生产代码的具体版本，能够回忆出来的话就从那个版本拉一条分支出来修复问题并测试发布。然后再去master上把相同的代码再改一次，紧急发布分支就不合回master。

要是回忆不起来版本号的话，那么就只能加班加点测试完master代码，直接发布主干，也就是我们上面发生的情况。

其实代码管理也算是范质量管理里的一部分。如果团队规模比较小的话，我们可以采用下面的模型

• 主干: 稳定的代码
• 开发分支: 从主干拉出来，开发都提交都开发分支，发布之前将代码合回主干
• 发布分支: 开发分支直接合到发布分支
• hotfix分支: 紧急bug修复，从发布分支拉，然后合回发布分支

配合一些持续集成或者工程化实践，稳定主干模式可以在短时间极大的提升项目质量(前提是当前项目的质量有极大的提升空间)。

• 对主干进行daily build，每天定时自动化回归
• 每次开发分支合入主干进行后进行自动化回归
• hotfix后对hotfix分支进行自动化回归

自动化用例的组成建议是

• 40%左右的单元测试
• 40%左右的接口测试
• 20%左右的ui测试

建议用例运行时间不超过20分钟。

回到上面的问题，如果是稳定主干的话，我们可以直接从线上的发布分支拉出hotfix分支，在该分支上进行紧急问题的修复，修复后进行自动化回归，没有问题的话就合到发布分支，发布到线上。最后将修改内容同步到开发分支即可。

有了这样的代码管理模型，测试同学大概可以避免在夜深人静强上全量代码时留下没有技术的泪水吧。