文章讲述了团队在经历服务不稳定后，通过改进开发流程，如创建稳定分支、延长测试时间以及实施假日准备期的软硬moratorium，成功提升了服务稳定性。关键步骤包括定期创建Release分支、确保测试充分和在重要时期避免非必要更新。
那么在减少了上线前的临时修改后，我们的服务更稳定了吗？
有一点改善，但并没有完全解决，服务还是不太稳定，而且很多服务器故障并不是由于上线前的临时修改导致的！
这就说明上线前的临时修改并不是导致服务不稳定的根本原因，那么到底是什么原因导致的服务不稳定？
于是我们又尝试了一些探索和改进，比如说增加更多的自动化测试、上线后对主要功能做一些手动的检查。这些方法都有一点效果，但都属于治标不治本的措施，服务还是不算稳定。
是什么原因让服务不稳定
对于这个问题我一直没有答案，直到几个月后，又一年的“Holiday Readiness”，也就是美国的购物季，从万圣节开始一直持续到新年，商家有各种促销打折活动，民众也是各种买买买。这期间对于我们这种线上消费类网站来说，稳定性要求特别高，当机一点点时间都可能造成巨大损失。
如何保证服务的稳定呢？根据我们过去几年的血泪教训中总结出来的经验，保证服务稳定的最简单有效的措施就是：节日期间不更新，除非必要的小更新和补丁！
所以在消费季，我们会实行“Soft/Hard Moratorium”，也就是“Holiday Readiness”期间，我们不上线新功能，只做必要的补丁更新以修复一些严重的线上故障。并且上线需要有严格的审批流程。
为了应对公司的“Soft/Hard Moratorium”策略，我们组也做了一些调整：
-
首先我们创建了一个holiday的branch分支，这个分支只修复生产环境的Bug或者必须的新功能更新。其他常规的开发依然放在master主分支。
-
然后每次holiday分支的修改在部署生产环境前，都预先在测试环境测试一周左右时间，测试没问题后再部署生产环境。
这样实施下来，在“Holiday Readiness”结束的时候，我发现我们的服务异常的稳定，虽然有过数次更新，但是一次故障都没有发生。这给我很多启示，让我意识到之前服务之所以一直不稳定，有两个主要原因：
原因一：没有一个稳定的可随时发布的分支
首先，我们的版本发布是基于master分支发布的，新功能和Bug修复的PR都会合并到master，这就意味着master分支一直是不稳定的。
在以前每两周一个Sprint的时候，这个问题就存在，只是当时因为测试时间更长，所以没有暴露出来。当改成每周一个Sprint后，这个问题就很严重了，导致了很多上线前的临时修改。
在“Holiday Readiness”期间，我们有一个稳定的holiday分支，这个分支只有bug修复，几乎没有新功能的代码，所以相对要稳定很多。
原因二：测试时间不够充分
在以前每两周一个Sprint的时候，我们有3-5天的时间测试，有大的问题问题基本上能在测试环境发现，当改成每周一个Sprint后，留给测试的时间只有1-2天，这点时间是很难充分测试的，所以很多问题要在上线后才暴露出来。
在“Holiday Readiness”期间，在每次代码修改后发布前，在测试环境都会有一周左右的测试时间，这样Bug就能得到充分的暴露，而不至于到生产环境才发现，而导致回滚或者补丁。
既然已经发现了问题所在，怎么去改进就相对容易了。所以我针对当前流程提出了一些改进的建议。
每个Sprint对应一个稳定的分支
对于没有稳定分支的问题，很好解决，那就是在每次Sprint完成，我们都创建一个对应的Release分支，Release分支创建好后，类似于我们之前在holiday分支做的那样，只做Bug修复，不增加新功能代码。
对于前面说到的上线前临时修改，如果是紧急Bug更新，那么放到Release分支，如果是其他的，则只合并到master分支，不会影响到release分支。
给测试留足时间
对于测试时间不够的问题，一个简单可行的方案就是回到两周一个Sprint的开发方式。但是大家已经习惯了一周一个Sprint的节奏，尤其是产品经理，希望新功能能尽早上线，更喜欢保持一周一个Sprint。
那么怎样在一周一个Sprint的情况下，保证有充足的时间测试呢？
于是我提出了一个简单可行的方案：在“Holiday Readiness”结束后，推迟第一个Sprint的上线时间一周。
具体做法是：我们的第一个Sprint完成后，不上线生产环境，在测试环境保留一周，同时开始第二个Sprint的开发，等到第二个Sprint开发完成后，上线第一个Sprint的版本，第二个Sprint的版本发布到测试环境测试一周，同时开始第三个Sprint的开发。
如图所示
这就意味着我们每一个Sprint开发完成，有完整的一周时间进行测试和Bug修复，但我们还是可以每周一个版本部署生产环境。
经过这样的调整后，我们的服务马上就稳定下来了，基本上不用担心发布后会有严重的质量问题，也极少需要上线后回滚或补丁。
当然这样调整后，也带来一些小的问题：
问题一：有两个Sprint在并行
在当前Sprint开发的同时，还要对上一个Sprint的Bug进行修复。但一般Bug的修复都比较简单，这样并行并没有带来太多的问题，我们的开发人员对这种模式适应的很好。
问题二：多分支管理
由于每个Sprint都会创建一个分支，那么意味着修复一个Bug，有可能要将修改同时合并到多个分支。
举例来说，在生产环境发现一个问题需要打补丁，那么这个PR要合并到生产环境版本对应的分支，还要合并到测试环境版本对应的分支，最后还要合并到master；如果在测试环境发现的Bug，需要同时合并到测试环境版本对应的分支和master。
不过相对于稳定性带来的提升，这一点不便还是完全可以接受的。
问题三：开发过程不易理解
这个开发模式在我们组内部运行的很好，但是对于组外的人来说，不是很容易理解，对于他们来说，最关心的是：我的需求或者PR什么时候能部署到测试环境，什么时候能部署到生产环境。
于是我们开发了几个工具，可以直观的知道当前开发中的是在哪个版本，测试环境是哪个版本，生产环境是哪个版本。
(电视投影)
配合这样的小工具，无论是组内还是组外，都可以很直观的了解当前的开发状态了。
总的来说，新的开发流程实行后，虽然存在一些小的麻烦，但是运行的很不错，服务的稳定性大幅提升。release分支让我们有一个随时可以发布的稳定版本；一周的测试时间可以很好的保证质量；同时每周一个版本的发布频率也可以让我们及时响应需求，有问题能及时发现。
Chrome的开发流程
无独有偶，后来我发现Chrome的开发流程，和我们现在的这套开发流程很类似，它是6周的开发流程，其中上一个版本的测试和当前版本的开发也是重叠的。
最后
码字不易，觉得有帮助的可以帮忙点个赞，让更多有需要的人看到
又是一年求职季，在这里，我为各位准备了一套Java程序员精选高频面试笔试真题，来帮助大家攻下BAT的offer，题目范围从初级的Java基础到高级的分布式架构等等一系列的面试题和答案，用于给大家作为参考
以下是部分内容截图
png)
最后
码字不易，觉得有帮助的可以帮忙点个赞，让更多有需要的人看到
又是一年求职季，在这里，我为各位准备了一套Java程序员精选高频面试笔试真题，来帮助大家攻下BAT的offer，题目范围从初级的Java基础到高级的分布式架构等等一系列的面试题和答案，用于给大家作为参考
以下是部分内容截图
[外链图片转存中…(img-Drn6xLoc-1714166002152)]
3471
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
