Jenkins拾遗--第四篇-适当的让构建失败

问题的引出：

有一段咱们的前端构建总会现git上分支名称中的版本号和工程里的版本号不一致的问题：这样会致使构一个问题：构建后的产品名称叫作1.1，可是进入app的关于页面，看到的版本仍是1.0。这会让人很困惑，也会加大弄混被测物版本的风险。
最初，咱们向开发提了这个问题，而且写了一份简要的说明文档贴在内部wiki上。结果发现效果并不理想，一部分开发会依照约定这么作，可是一部分开发不会这么作。因为多人多feature开发，这样的问题每2周就会出现一次，还很很差排查。维护Jenkins的小伙伴很郁闷，由于这样老去找开发同事费时费力。
通过讨论，咱们加入了一个fail条件： “若是git分支名称上的版本号和工程文件中的版本号不一致，则构建失败，而且明确给出失败缘由（wiki的连接贴出来）”
咱们默默的加入了这个条件后，发现问题不再存在了。历来没有开发找来，咱们翻看构建历史，发现有这样的构建失败样例，可是后续开发就自助的修改了（给出wiki连接后，估计5分钟他们就能明白问题，并搞定）。

问题的总结：

1.在IT项目中咱们常说一句话：约定大于配置。这句话在很大程度上是对的，但不必定彻底奏效。上面就是一个反例。
2.口头约定不必定有效的状况下，若是成本不高，采起一些强制措施会有用。一个例子是：强制静态代码检查，虽然会给不少人带来痛苦，但会有效提升代码质量。
3.具体就这件事儿来讲：在构建过程当中作必定检查是必要的，之前忽略了这个问题。后续的改进工做是检查别的Job存不存在这样的检查点，若是有，加上。