本發(fā)明涉及一種監(jiān)管及跟蹤方法，尤其涉及一種基于githooks和缺陷管理工具的監(jiān)管及跟蹤方法。
背景技術：
目前，現(xiàn)有的大多數(shù)gitlab使用者都只是使用默認的githooks，從而忽視了githooks的可定制、將git與缺陷管理工具結合起來控制代碼的提交動作、以及將代碼提交記錄到缺陷管理工具，便于問題追蹤定位。
技術實現(xiàn)要素：
本發(fā)明的目的在于克服目前大多數(shù)gitlab使用者沒有很好的利用githooks的可定制性，并結合缺陷管理工具來監(jiān)控并跟蹤代碼的提交的缺陷，提供一種能通過定制githooks，并結合bugzilla來控制代碼的提交，從而便于問題追蹤定位的基于githooks和缺陷管理工具的監(jiān)管及跟蹤方法。
本發(fā)明的目的通過下述技術方案實現(xiàn)：
一種基于githooks和缺陷管理工具的監(jiān)管及跟蹤方法，包括以下步驟：
(1)通過git客戶端向git上的工程分支提交代碼，提交代碼時填寫message中的信息，message中的信息包括需求id或者bugid；
(2)git服務端收到分支代碼的push請求時，將調用githooks服務端的pre-receive腳本；pre-receive腳本根據(jù)git命令獲取到代碼的提交記錄以及message中的需求id或者bugid，并根據(jù)需求id或者bugid從缺陷管理工具中獲取到id的具體信息；
(3)pre-receive腳本根據(jù)從缺陷管理工具中獲取到id的具體信息判斷該id的狀態(tài)是否允許提交代碼、該id對應的bug是否為可修改狀態(tài)、提交代碼的git分支與該id對應的分支是否一致；
(4)當步驟(3)判斷結果全為“是”時，則pre-receive腳本將代碼的提交記錄寫入缺陷管理工具的相關id下，并且在寫入成功后返回給git客戶端“提交成功”；否則返回給git客戶端“提交失敗”。
進一步的，步驟(1)中message的格式為【需求#id】comments、【requirement#id】comments、【錯誤#id】comments或【bug#id】comments。
再進一步的，步驟(2)中從缺陷管理工具中獲取到的id的具體信息包括：需求或者bug對應的git分支、需求或者bug對應的狀態(tài)以及該bug的優(yōu)先級。
為了更好地實現(xiàn)本發(fā)明，步驟(2)中pre-receive腳本通過缺陷管理工具的api接口獲取id的具體信息。
為了確保效果，所述缺陷管理工具為bugzilla或redmine。
本發(fā)明較現(xiàn)有技術相比，具有以下優(yōu)點及有益效果：
(1)本發(fā)明不僅步驟簡單、方便操作，而且能規(guī)范代碼提交流程，可便于問題追蹤；通過定制githooks并結合缺陷管理工具來監(jiān)控和跟蹤代碼的提交，不僅能夠減少亂提代碼造成的問題，同時能夠在出現(xiàn)問題的時候快速追蹤定位，保證產(chǎn)品質量，減少開發(fā)測試成本。
(2)本發(fā)明對于代碼的提交只做了三種條件的控制，如果有其他需要，可以根據(jù)情況隨意增加，方便擴展。
(3)本發(fā)明的缺陷管理工具可以根據(jù)需要選用bugzilla或redmine或者其他任意提供了api接口的類似工具，因此使得本發(fā)明實施時更加靈活方便。
具體實施方式
下面結合實施例對本發(fā)明作進一步地詳細說明，但本發(fā)明的實施方式并不限于此。
實施例
本發(fā)明的基于githooks和缺陷管理工具的監(jiān)管及跟蹤方法，首先通過git客戶端向git上的工程分支提交代碼，提交代碼時填寫message中的信息，該message中的信息包括需求id或者bugid。其中，message的格式可以為【需求#id】comments、【requirement#id】comments、【錯誤#id】comments或【bug#id】comments。
然后，git服務端收到分支代碼的push請求時，將調用githooks服務端的pre-receive腳本。git具有在特定事件發(fā)生之前或之后執(zhí)行特定腳本代碼的功能，githooks就是那些在git執(zhí)行特定事件(如commit、push、receive等)后觸發(fā)運行的腳本。githooks腳本所在的位置可以分為兩類：本地hooks，觸發(fā)事件如commit、merge等；服務端hooks，觸發(fā)事件如receive等。服務器端hooks的pre-receive腳本為定制腳本，在push代碼到遠程倉庫的時候觸發(fā)。
然后，pre-receive腳本根據(jù)git命令獲取到代碼的提交記錄以及message中的需求id或者bugid，并根據(jù)需求id或者bugid從缺陷管理工具中獲取到id的具體信息，所述pre-receive腳本是通過缺陷管理工具的api接口獲取id的具體信息。其中，從缺陷管理工具中獲取到的id的具體信息包括：需求或者bug對應的git分支、需求或者bug對應的狀態(tài)以及該bug的優(yōu)先級。所述缺陷管理工具為bugzilla、redmine或者其他提供了api接口的類似工具，使用時可根據(jù)需要進行選用，本實施例中的缺陷管理工具以bugzilla為例進行說明。
再然后，pre-receive腳本根據(jù)從bugzilla中獲取到id的具體信息判斷該id的狀態(tài)是否允許提交代碼、該id對應的bug是否為可修改狀態(tài)、提交代碼的git分支與該id對應的分支是否一致。實施時，需求或者bug對應的git分支記為“gitbranch”，需求或者bug對應的狀態(tài)記為“bugstatus”，該bug的優(yōu)先級記為“bugpriority”。接下來判斷該id的狀態(tài)是否允許提交代碼，當“bugstatus”為已驗收、已拒絕、已發(fā)布或已關閉狀態(tài)時不允許提交代碼，否則允許提交代碼。判斷該id對應的bug是否為可修改狀態(tài)時，當“bugpriority”為p1時id對應的bug為可修改狀態(tài)，當“bugpriority”為p2時id對應的bug則為不可修改狀態(tài)。其中，在bugzilla中“p1”的定義是“可修改”，而p2的定義是“不可修改”。判斷提交代碼的git分支與該id對應的分支是否一致時，預先在將通過git客戶端向git上的工程分支提交代碼時記為“x”分支，當“gitbranch”為x分支時候允許提交代碼，否則不允許提交代碼。上述三個判斷結果全為“是”時，即判斷id的狀態(tài)為允許提交代碼、且判斷該id對應的bug為可修改狀態(tài)、同時判斷提交代碼的git分支與該id對應的分支一致時，則pre-receive腳本將代碼的提交記錄寫入缺陷管理工具的相關id下，并且在寫入成功后將結果“提交成功”返回給git客戶端；否則將寫入失敗結果“提交失敗”返回給git客戶端。
如上所述，便可較好的實現(xiàn)本發(fā)明。