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

问题的引出：

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

问题的总结：

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