如果你的团队认为这个指标没有价值，建议先在团队内讨论清楚价值所在，否则就没必要看这个指标了。
先明确一下这个指标的计算公式：CI失败一小时修复率=（构建成功次数+构建失败一小时内修复次数）/构建总次数。即要尽量减小构建失败后修复超过一小时的次数，这个指标的关键在一小时，下面我们详细说一下如何达成。
尽量短的时间内发现问题，一次构建的时间建议不要超过10分钟，否则很难达成这个指标。因为通常一次失败到修复要使用这么多时间：（构建时间+定位修复问题时间）*尝试修复次数+通知到人等响应时间，如果构建的时间为10分钟，定位修复问题为15分钟，则最多可以尝试修复2次，所以一定要优化。优化可以考虑增量编译、并行编译、换好的硬件、删除非必要节点等（例如覆盖率统计，如果审计需要可以再建一个CI）。做了以上优化以后我们的构建基本控制在5分钟左右，由于ZCIP不支持提交代码自动触发构建，变通的设置为判断代码变更1分钟执行一次来实现，这样一提交代码几分钟就会有构建结果出来。另外要发现更多的问题则必须依赖单元测试，其他的测试不够快，这个请结合团队的情况开展吧。
尽量短的时间内通知到问题人并马上着手修复，ZCIP的邮件提醒就不考虑了，持续构建灯可以搞一个，缺点是没有交互，如果坐的距离灯比较远不容易发现，要有人在QQ群里问和认领。后来工作群换了钉钉，使用其开放了机器人接口做通知，写了一个脚本大概实现这样的功能：构建失败时@所有人具体哪个流程失败了谁来认领并请其他人修复前不要提交代码，失败45分钟后如果没修复再广播通知是否需要回退代码，修复后@所有人本次修复次耗时多久可继续提交代码。通常收到第一个通知几分钟前提交代码的人会认领并开始排查，如果没人认领流程负责人检查修改记录再通知责任人排查。目前保持构建灯+钉钉通知的方式效果比较好。
开发自测环境与CI流程保持一致，具备快速构建测试的能力，尽量缩小开发环境和CI构建环境的差异，我们都换成了eclipse在linux上开发，例如提取一个函数工具直接帮你完成，点一下编译并执行单元测试通过就可以提交了。为了快速发现并修复问题要小步提交，这样别人走查也容易看懂，回退也很容易。
排除干扰，例如ZCIP不稳定，环境因素等非代码问题，这些应该尽量由团队负责人负责联系支撑单位优先处理，排除对团队成员的影响，避免打击大家的积极性。
坚持并养成习惯，以上都做到了只要坚持一段时间，让团队成员都养成习惯即可。
网友评论