git及gitlab在項目開發中的實踐應用二

以前寫過實踐應用一，內容比較入門，基本使用狀況和你們同樣，做爲一個管理代碼的工具。今天這篇屬於高級篇，結合咱們使用的狀況重點介紹下git和gitlab的擴展應用。

git 鉤子

我碰到個場景，須要在代碼merge以前，就判斷出代碼或者相關的內容合不合規，而gitlab的CI事件都是後置觸發。即便判斷有問題，動做提交發生了，若是rd沒有等到後置判斷的結果，而又去處理其餘事情了。當有問題的時候，再去修改。整個過程時間比較長，不如在用戶提交的時候就去作些判斷，通過對比調研。感受git鉤子比較適合。

git鉤子安裝

關於git鉤子的介紹，這裏簡單說下，git鉤子的代碼是在本地的，不在代碼庫中。地址通常在你項目的 .git/hooks/ 裏面，以下圖，能夠看到不少的文件，對應git不一樣的動做，選擇一個去掉結尾的 .sample 就能夠了。

場景實現

還須要考慮一點，怎麼能讓全部人都強制安裝上，成爲開發的必須一步。此時，注意到咱們的項目代碼使用了php composer，即：某些公共模塊寫成了 composer 包的形式，放在內部私有庫上。部署開發環境，須要執行一步。咱們也採起一樣的方式，寫成了一個 composer 包的形式。而後在composer的腳本中，作處理。結合咱們的項目特色以下流程：

相關步驟：

一. 開發 php composer 擴展包。

二. 基於咱們現實的狀況，項目初次須要執行composer install/update。這樣咱們就把第一步的包加載引入到了項目裏面。

三. 在 composer 的腳本里面加入執行語句，執行一個腳本。腳本主要實現檢測 git 鉤子對應的內容是否存在，文件同第一步的文件比較是不是最新的。

腳本位置可參考composer.json以下內容：

"scripts": {        
   "post-install-cmd": [            
       "@php -r \"include '項目腳本目錄/check.php';腳本語句(__DIR__);\""],
   "post-update-cmd": [
       "@php -r \"include '項目腳本目錄/check.php';腳本語句(__DIR__);\""],
   "post-package-install": [
      "@php -r \"include '項目腳本目錄/check.php';腳本語句(__DIR__);\""],
   "post-package-update": [            
      "@php -r \"include '項目腳本目錄/check.php';腳本語句(__DIR__);\""]
},

四. 若是第三部中檢測到沒有安裝，或者不是最新的。則進行拷貝，更改文件的權限爲能夠執行。

執行的效果

當以上步驟都執行後，咱們就能夠實際使用了，固然，我這裏只用到了 post-checkout（開發初期，切換分支提示去幹某些事）和 commit-msg腳本 (提交代碼標籤檢測，提交信息檢測)。

1. 當需求新創建時，通常會 git branch xxx && git check xxx，而後 post-checkout 腳本就被觸發了，提示你去幹什麼事。

    2. 代碼功能完成，提交時進行一些檢測。

以上，有興趣的同窗能夠深刻探討。

gitlab issue

業界有不少專業的管理需求的軟件，公司內部也有jira等工具，但結合友軍和業務實際狀況考慮。咱們採用gitlab issue進行作需求跟蹤。先說下背景：業務方多，平時需求對接各式各樣，QQ，微信，最好的發送個郵件。業務跟蹤困難。單項業務週期短，而考察了幾個兄弟部門的狀況和網上的介紹，整齊劃一選擇issue做爲項目需求管理的工具。

gitlab onboard

這裏不得不說 gitlab 的看板功能，這個作簡單項目跟蹤一目瞭然。業界包括不少著名的公司，都用看板功能去跟蹤需求進度。我看了某些著名保險公司的團隊項目管理的視頻，有些團隊真的準備了一塊白板，而後經過貼紙條的形式，完成看板功能。而後天天開晨會的形式去跟進狀態。

默認的欄目能夠分紅以下幾種：

  Doing => To Do => Closed

固然，你也能夠根據實際須要，按照你的定義分類。而後給每一個issue貼上對應的標籤，就能夠反映出狀態了，以下圖是咱們的線上實際狀況展現。

Webhooks

我這裏還有一個玩法：Webhooks，咱們來看官方的介紹：

Webhooks can be used for binding events when something is happening within the project.

應用場景：怎麼知道你的issue創建的對不對，格式有沒有問題。當狀態更新的時候能不能作些什麼。代碼merge request的時候，是否須要作些聯動等等。如下是咱們的使用狀況：

gitlab CI

和業界小夥伴使用方法同樣，咱們這裏主要體如今幾個方面：

1. 提交代碼以後，觸發CI的規則，在裏面作些檢測，如：相關代碼規範，單元測試等。

2. 結合jenkins作持續集成。在項目的gitlab CI對應的配置文件裏面對應的規則和對接jenkins的接口，這樣當你對代碼作某種操做，如打符合既定特徵的tag的時候，就能夠觸發jenkins任務了，在jenkins裏能夠進行構建鏡像，代碼上線等內容。

以上，僅是我站在我的的角度，對接觸到的git和gitlab的一些總結，過程的探索了離不開你們基於自身項目的情況進行的不斷嘗試。若是你們有什麼想了解的更細緻的，請聯繫我。