bash99
2017-10-17 15:28:06 +08:00
说个在小 team 里面实现得还过得去的模式（当时 docker 还不够流行）
前提：
1. 强大的测试能力或者说自动化测试
我们的测试哥们工资很高，能指导开发数据库设计不合理，能写自动化测试
2. 较好的线上环境重建能力；包含标准测试数据库依赖的环境 5 分钟（也就是不管因为测试把数据库弄得怎么样了，5 分钟全套回复到标准环境）；线上数据库脱敏重建 30 分钟；
3. 变更管理较完备，数据库变动版本化进入代码。
做法：
敏捷模式，每周 release，但是每 2 ～ 4 周为一个 sprint，每个 sprint 里面程序员手头 3 ～ 6 个功能 /Fix，每个功能一个分支。少数情况 2 ～ 3 人工作在一个分支上
hotfix/紧急变动在测试通过后会迅速合并到 master
分支提测前，会保证合并了当前 master （普通 merge 模式；不 rebase -- 当时大家 rebase 用得实在不熟，否则 rebase 应该也行）。会要求程序员做基本自测。
自动化测试通过后，该分支会被合并到一个测试环境（代码包括所有提测的分支），合并有冲突会打回让程序员自己去兼容其它分支（这个情况比较少，可能也是比较麻烦的，基本上让他们本地拿测试分支 merge 找问题）；这个测试环境会再来一轮自动化，有问题也打回，然后 revert （这两步后期是土法脚本化了）；
然后在这个环境上做对应的新功能测试，有问题也是 revert 掉这个分支带来的改动。
周五下午会决定哪些功能在上述环境上已经稳定并且准备上线，所有待上线分支都冻结，然后单个分支 squash merge 到 master。对这个 master 做一些最后测试并确认。
周一上线。（只有脚本自动化，有回退，但是没有灰度发布，有数据库变动且不兼容回退也碰到过，这个没完美解决好）
之后删除已上线两周的老分支（少数重要分支打 tag 后删除）。
优势是 master 上都是干净的一个个功能 commit 和部分 hotfix。
另外，如果分支跨了 sprint，基本上也是很烦的，和其他分支冲突几率大大增加；通常我们在回顾会上检讨是产品经理粒度不合适还是开发没做好。
现在有 docker 了按说可以把上面的自动化测试和环境重建做得更好方便。我仍然觉得 CI 流程做好了是基础，git 只是更灵活更能适应各种的 CI 流程而已。
