Jenkins拾遺--第四篇-適當的讓構建失敗

問題的引出：

有一段咱們的前端構建總會現git上分支名稱中的版本號和工程裏的版本號不一致的問題：這樣會致使構一個問題：構建後的產品名稱叫作1.1，可是進入app的關於頁面，看到的版本仍是1.0。這會讓人很困惑，也會加大弄混被測物版本的風險。
最初，咱們向開發提了這個問題，而且寫了一份簡要的說明文檔貼在內部wiki上。結果發現效果並不理想，一部分開發會依照約定這麼作，可是一部分開發不會這麼作。因爲多人多feature開發，這樣的問題每2周就會出現一次，還很很差排查。維護Jenkins的小夥伴很鬱悶，由於這樣老去找開發同事費時費力。
通過討論，咱們加入了一個fail條件： 「若是git分支名稱上的版本號和工程文件中的版本號不一致，則構建失敗，而且明確給出失敗緣由（wiki的連接貼出來）」
咱們默默的加入了這個條件後，發現問題不再存在了。歷來沒有開發找來，咱們翻看構建歷史，發現有這樣的構建失敗樣例，可是後續開發就自助的修改了（給出wiki連接後，估計5分鐘他們就能明白問題，並搞定）。

問題的總結：

1.在IT項目中咱們常說一句話：約定大於配置。這句話在很大程度上是對的，但不必定徹底奏效。上面就是一個反例。
2.口頭約定不必定有效的狀況下，若是成本不高，採起一些強制措施會有用。一個例子是：強制靜態代碼檢查，雖然會給不少人帶來痛苦，但會有效提升代碼質量。
3.具體就這件事兒來講：在構建過程當中作必定檢查是必要的，之前忽略了這個問題。後續的改進工做是檢查別的Job存不存在這樣的檢查點，若是有，加上。