1. 程式人生 > >即拉即用:你不知道的持續整合的3個Git Hooks詳解

即拉即用:你不知道的持續整合的3個Git Hooks詳解

在構建之外新增自動化的手段,是真正用好CI的關鍵。

如果你已經用了一段時間的Git了,相信你可能聽說過Git Hooks,甚至可能簡單的上手玩了玩。

Git Hooks在持續整合的語境中十分神奇,所以在本文中,我將深入介紹三個用例,並教你學會將現成可用的Hooks運用到你的工作流程中。 如果你還是Git Hooks的菜鳥,也完全不用擔心, 因為我們將從基礎開始。

1.瞭解Git Hooks

Hook是Git系統的本地機制,用於在諸如程式碼提交(Commit)和合並(Merge)之類的操作之前或之後觸發的定製化指令碼,可以把它們看作是Git的外掛系統。對Git-hooks有一個入門認識的朋友都知道, 如果你進去檢視Git的.git目錄,你將看到一個“hooks”的子目錄,裡面包含很多Hook指令碼。

圖片描述

安裝Git Hooks其實很簡單,網上也有很多供查閱的參考文件,在此就不討論這個問題了。

按照Git Hooks指令碼所在的位置可以分為兩類: 客戶端Hooks和伺服器端Hooks。

客戶端Hooks在本地工作站執行, 而伺服器端Hooks則在你的Git伺服器上執行。

還可以將Hook分類為Pre- 或Post-。Pre-receive Hooks指令碼在某些特定的Git操作之前被呼叫, 可以利用這個Hook指令碼來檢查推送過來的提交是否合法,如不合法,Git操作不被執行,即客戶端的推送會被拒絕。它們實際扮演一個保鏢的角色,從後臺保護程式碼庫, 防止你和專案成員提交錯誤的程式碼。當從客戶端(本地庫)完成一個推送後, Post-receive Hooks將執行,它不會拒絕Git程式碼提交,但可以完成開發工作流程中的一系列自動化任務。

使用Git Hooks,就像擁有一個小機器人助手, 可以實現Git相關的一系列自動化任務 (哈哈!)

Git Hooks可實現專案開發流程的一系列自動化任務,例如下面幾點:

驗證你在提交訊息中包含了關聯的JIRA金鑰
在程式碼合併前,確保滿足先決條件
傳送通知給你開發團隊的聊天室
在切換到不同的工作分支後,設定你自己的工作區

圖片描述

2.建立穩定健康的工作分支

伺服器端 Pre-receive Hooks是持續整合中的一個特別有力的補充,可以利用它來檢查程式碼是否符合某些條件,防止開發人員隨意將程式碼推送到master,就像精英忍者守護者一樣,保護程式碼庫不受惡意程式碼的影響。

開發人員通常都有足夠的責任心,當他們在自己的工作分支測試上出現問題時,他們不會將分支合併到主程式。但有時我們卻忘了檢查,特別是當我們和其他人共享一個工作分支的時候,這時候會發生更多的更改或變化,雖然我們上次已經檢查了分支的情況,但沒想到問題還是出現了。。。。。。

此時,你就可以使用一個伺服器端Hook,用於查詢進入master的合併, 找到時, 指令碼將檢查分支上最新的構建,如果有測試失敗的情況,那麼合併就會被拒絕。我的同事和Atlassian的開發者Tim Petterson為此編寫了一個Hook指令碼

旨在與Bamboo合作,並使它在Bitbucket上可完美運用。 你可以把它抓下來,定製它,並將其新增到你的程式碼庫中。

3.保護你來之不易的程式碼覆蓋率

我看到很多開發團隊都在努力維護程式碼覆蓋率。 很多情況下,他們不得不通過測試來追溯他們的原始碼庫。在沒有經過測試驗證支撐的情況下,當很多功能被新增進來時,好不容易達成的程式碼覆蓋率每況愈下,看到這樣的情景,實在令人心灰意冷。因此,Tim還編寫了一個pre-receive伺服器端Hook,來保護master程式碼覆蓋率不再下降。

圖片描述

這個Hook也可以查詢進入到master的合併,然後呼叫持續整合伺服器來檢查master以及分支上的程式碼覆蓋率。如果分支的覆蓋有任何問題,則合併將被拒絕。

大多數持續整合伺服器不會通過它們的遠端API顯示程式碼覆蓋資料,但Git Hook指令碼可以獲取程式碼覆蓋報告。 要做到這一點,構建必須設定為將程式碼覆蓋報告在master和工作分支上作為共享件釋出。 一旦釋出,你可以通過呼叫持續整合伺服器從master獲取最新的覆蓋報告。對於分支覆蓋,你可以從最新的構建中獲取覆蓋報告,也可以從正在提交的merge相關分支獲取覆蓋報告。

需要說明的是, 上述實踐的前提是你已經運行了程式碼覆蓋。別指望這個Hook來幹這件事——它只是在你的構建結果中查詢覆蓋率資料而已。 預設情況下,這個指令碼也適用於Bamboo,以及Clover(Atlassian的Java和Groovy程式碼覆蓋工具)。但是它可以定製成與構建伺服器或程式碼覆蓋工具結合在一起使用。

4.檢查分支構建的狀態

朋友通常不會讓朋友去檢驗有問題的分支。

那麼此時,我們就可以利用另一個客戶端Git Hooks: post-checkout Hook指令碼,同樣也是由Tim編寫的,它在你的終端視窗中顯示分支建立狀態。該指令碼從本地副本獲取分支的頭版本號,然後查詢持續整合伺服器,檢視是否已經建立了該版本,並檢查建立是否成功。

圖片描述

比如,你想在master中建立分支,這個Hook會告訴你, master上的head commit是否成功建立,這意味著可以用這個“安全的”提交來建立分支。 再如,如果這個版本的分支構建失敗了,但是開發團隊的牆板卻顯示了一個綠色建立(或者正好反過來)。這意味著你的本地副本已經過期了,你可以自已決定是要更新版本還是繼續使用舊版本的本地副本進行操作。

使用這個Hook對Atlassian的開發人員來說是無疑是一大神器,使他們避免了無數頭痛的困擾。如果你實在不能說服你的開發團隊採用上面討論的伺服器端Hook,那至少可以在你的本地工作站上安裝一個,相信你絕對不會後悔的!

我在這裡演示的所有用於持續整合的Git Hooks, 預設都是基於和Bamboo、Clover、Bitbucket 結合使用的情形,但是請記住,Git Hooks實際上是廠商無關的,因此你可以將它們定製成與你自已的編碼工具結合使用,從而在開發過程中實現真正的自動化。

關於作者:
莎拉是一位Atlassian敏捷交付傳道者,之前是一名測試自動化工程師,還是簡化書呆子式生活的忠實擁躉。例如,像持續整合和自動化一樣。手動測試越來越變得枯燥無趣,她試圖作出一些改變。她所崇拜的人包括瑪格麗特·撒切爾夫人、麥吉弗和她的母親。