1.2 建立代码门禁
笔者每次接手一个团队，要做的第一件事情都是看这个团队有没有代码门禁（Gated Checkin）。没有代码门禁的团队，虽然会在每次代码提交后触发持续集成（主要是编译代码、执行单元测试和接口级别功能测试），但结果不稳定，大部分时间是无法做到测试用例100%通过的，而且经常是一边修复，一边出现新的失败用例。久而久之，团队在迭代过程中不再关注用例的结果，而是等到迭代后期一次性地修复所有问题，单元测试和接口测试的价值没有得到充分体现，无法在第一时间发现那些简单和基本的问题。所以，团队要做的第一件事情就是把代码门禁建立起来。
1.2.1 什么是代码门禁
在有代码门禁之前，开发人员都是通过git push origin命令将代码直接提交到远程的项目分支和迭代分支的。虽然我们一直明确要求开发人员必须确保代码在本地通过编译及所有的单元测试和接口级别的功能测试后才能提交，但有些工程师偶尔会不遵守这个规定。另外，有时候，虽然代码能在本地通过测试，但由于环境的差异，这些代码在其他地方运行时还是会失败的。而代码门禁可彻底杜绝这些问题。
代码门禁的做法大体如下。
在公共分支（包括项目分支、迭代分支、主干分支、紧急发布分支）上，禁用git push，只允许通过pull request来提交代码。
我们的研发平台对每个提交到公共分支的pull request都会执行各项检验，包括编译、单元测试和接口级别功能测试、静态代码扫描。只有通过这些检验，pull request才能够被合并。
换句话说，代码门禁就是简单地把持续集成前移：从代码提交后（post-submit）提前到了代码提交前（pre-submit）。这简单的前移，彻底改变了我们的研发模式：从以前的“先欠债再还”，变成了现在的“每个代码提交都不能欠债”。
1.2.2 代码门禁的效果
2018年的数据显示，阿里巴巴集团的一个团队平均每个月有超过3000次pull request执行了代码门禁，其中被代码门禁拦截的有问题的pull request约800次，占总数的20%以上。在被拦截的pull request里，代码编译问题（包括jar包依赖问题）约占1/2，用例失败约问题占1/4，静态代码扫描发现问题约占1/4，还有少数的其他检验发现的问题。可以想象，这些问题如果没有在代码提交前被及时拦截，会严重地影响公共分支上代码的质量。
1.2.3 落地和优化
在推进代码门禁之初，我们遇到了一定的阻力——代码门禁极大地改变了开发人员的代码提交习惯。原来只需要一个命令，几秒钟就能提交完成，现在要等上至少十几分钟。另外，由于代码门禁中执行的测试本身不稳定（这本身就是我们希望通过代码门禁来解决的问题），开发人员可能需要重运行一次或者多次才能让测试全部通过，进一步增加了代码提交需要的时间和精力。
因此，除了花大量时间向团队解释代码门禁的重要性，我们还做了一些比较关键的优化。
1．缩短时间
制定代码门禁的测试执行时间的目标。我们要求对于任何一个微服务（也就是一个Git代码库），代码门禁的测试执行时间都应该不超过10分钟。10分钟是一个经验值，时间更短，会让难度大大增加；时间更长，开发人员的体验会明显变差。
用基于MariaDB4j的本地数据库方案，解决了被测代码对远程数据库的依赖问题。被测代码对本地数据库的读/写延迟要明显小于对远程数据库的读/写延迟时间。
精准测试，只运行和变更代码相关的用例。我们记录每个用例的代码都覆盖详细数据，当代码门禁测试开始的时候，我们基于这个数据，反查出和变更代码相关的用例，只运行这些用例。据阿里巴巴集团某团队的数据显示，精准测试可以缩短代码门禁中43%的测试时间。
2．提高稳定性
制定了代码门禁的测试稳定性的目标，即90%的成功率。也就是说，整个测试用例集如果执行100次，其中至少应该有90次是通过的。90%也是经验值，是在实现难度和测试人员的体验之间做的折中。
本地数据库方案和精准测试也能提高稳定性。在使用了精准测试后，执行的用例数量少了，出现噪声的可能性也因此降低了。
经过这些优化，代码门禁中的测试又快又稳定，这反过来增强了开发人员对代码门禁的接受程度。因此，代码门禁的全面普及极大地提高了代码的入库质量。
1.2.4 更多的用途
代码门禁的机制运转顺畅以后，还可以很方便地承载更多的验证和卡点，举例如下。
BugJail：如果一个开发人员有很多高优先级的Bug长时间不修复，我们就可以把他关进“BugJail”，意思就是不允许其再开发新功能，必须先修复这些已有的Bug，直到他名下的Bug数量降到一定水平以下。代码门禁的机制可以用来实现BugJail，根据配置好的策略，对被关进BugJail的开发人员，代码门禁不允许其pull request合并。
代码围栏：对于一些核心代码，我们要求所有相关的pull request都要经过有经验的人员的代码检查。我们配置了一个代码门禁的规则，把通过这些人员的代码检查作为pull request合并的必要条件。
组件升级：我们有些内部的公共jar包被很多团队使用，但有些团队长期不升级这些jar包，带来了很高的维护成本，也埋下了质量风险隐患。代码门禁提供了一个强制升级的机制，即如果某个系统的该升级的jar包一直不升级，那么经过一个“黄牌警告”时期后，我们可以通过配置代码门禁的规则来阻断这个系统的所有pull request，强制升级。
有了代码门禁机制，以上场景很容易就可以实现，降低了研发协作平台新功能开发的工作量。
