总是签入代码到master有那么恐怖吗？

读《微服务设计》一书，其中一章讲到了持续集成，也就是CI（Continuous Integration）。其中介绍了一个有趣的问答故事。有个叫Jez Humble的人经常四处演讲，在讲解有关CI内容的时候，他总是喜欢问在场的人三个问题：

1、你是否每天都签入代码到master？

2、你是否有一组测试来验证签入master的修改代码？

3、当构建失败时，团队是否把修复CI当做第一优先级的事情来做？

只要回答了三个yes的人，那么恭喜你，你的团队正在使用CI。否则就不算是完全的CI。

这三个要求，在部分朋友看来是比较难做到的，甚至认为这是不对的。也许会有人会有这样的疑问：master怎么可以随便签入呢？

也许就是因为这一个疑问，就让很多人望而却步。

然而事实上，总是签入代码到master有很多的好处。这个好处是相对的。就是你不总是签入和总是签入二者哪个麻烦更少。通过这样的比较如果得出“总是签入”的麻烦更少的话，那么我们就认为“总是签入”是推荐的。

我之所以推荐CI，一个很简单的原因就是我不想总是建分支。老实讲，我对分支是有恐惧感的。我不知道一个持续时间很长的分支最后到底会回报我一个多大的礼包（bug列表）。

持续不断把代码集成到master，甚至直接使用主干开发会带来诸多的好处，这样做足够的敏捷和高效，而且事实上要比以分支为主的开发质量更高。

CI具有的特性：

• 只有一个Repository
• 自动build
• 自动测试
• 每个人至少每天提交代码到主干
• 每次commit都应该在一个集成机器上build主干
• 短时间修复构建遇到的问题
• 保证短时间内可完成build和test
• 测试是在一个线上环境的模拟版上进行（预发布环境）
• 让所有人都可以容易的得到最新的可执行代码和文件
• 每个人都可以知道代码最新的状态
• 自动部署

下面这个activitiy图是我从gitlab上截的，其中有一天居然commit了72次，注意这还是我一个人一天的提交数量。