前言
現在挺多公司使用gitlab管理代碼，我司也是。在開發人員發起代碼合入請求（merge request)時，如果能先進行一些前置檢查（包括單測、靜態檢查、編譯檢查等），那就既減輕了code review人員的負擔，也能更好的保證代碼的正確性和穩定性。以前jenkins是這方面的不二之選，不過現在gitlab自己也提供了一個叫gitlab runner的工具來做這件事，那么如何進行選擇呢，其實也沒有固定答案，完全根據需要和實際場景選用，下面我從自己的使用體驗來談談這兩個的優缺點，使用時間不長，可能並不會全面，特別是jenkins，只是簡單的安裝配置，沒有長時間使用。
jenkins:
優點：
發展時間較長，各種功能的插件多
各種操作和源代碼分離
獨立的頁面，可以管理多個項目
缺點：
配置相對復雜
需要進入web控制台查看編譯過程
gitlab runner:
優點：
和gitlab完全融合，在merge request頁面就可以看到結果
配置簡單，容易上手
缺點：
配置文件和源代碼在一起，相對不隔離
功能比jenkins少
如何選擇
個人感覺gitlab runner更適合全是開發的團隊（比如一個部門）使用，而jenkins適合有專門測試人員的公司或部門使用。gitlab runner 配置簡單，所見即所得，不需要單獨的web控制台，直接在gitlab即可查看各種檢查是否成功，而我們團隊沒有專門的測試，因此選擇gitlab runner更合適。如果未來有的需求gitlab runner無法滿足，再進行切換即可。