Jenkins

Jenkins作為老牌的持續整合框架，在這麼多年的發展中，積累很多優秀的plugin工具，對進行持續整合工作帶來很大的便利。

gitlab-ci

gitlab-ci作為gitlab提供的一個持續整合的套件，完美和gitlab進行整合，gitlab-ci已經整合進gitlab伺服器中，在使用的時候只需要安裝配置gitlab-runner即可。
gitlab-runner基本上提供了一個可以進行編譯的環境，負責從gitlab中拉取程式碼，根據工程中配置的gitlab-ci.yml，執行相應的命令進行編譯。

jenkins VS gitlab-runner

• gitlab-runner配置簡單，很容易與gitlab整合。當新建一個專案的時候，不需要配置webhook回撥地址，也不需要同時在jenkins新建這個專案的編譯配置，只需在工程中配置gitlab-ci.yml檔案，就可以讓這個工程可以進行編譯。
• gitlab-runner沒有web頁面，但編譯的過程直接就在gitlab中可以看到，不需要像jenkins進入web控制檯檢視編譯過程。
• gitlab-runner僅僅是提供了一個編譯的環境而已，全部的編譯都通過shell指令碼命令進行。當然，jenkins也可以是全部的編譯都通過shell指令碼命令進行。
• jenkins的好處就是編譯服務和程式碼倉庫分離，而且編譯配置檔案不需要在工程中配置，如果團隊有開發、測試、配置管理員、運維、實施等完整的人員配置，那就採用jenkins，這樣職責分明。不僅僅如此，jenkins依靠它豐富的外掛，可以配置很多gitlab-ci不存在的功能，比如說看編譯狀況統計等。如果團隊是網際網路型別，講究的是敏捷開發，那麼開發=devOps，肯定是採用最便捷的開發方式，推薦gitlab-ci。
• 如果有些敏感的配置檔案不方便存放在工程中（例如nexus上傳jar的賬戶和密碼或者是其他配置的賬戶密碼）,都可以在伺服器中配置即可。
• gitlab-ci對於編譯需要的環境，比如jdk，maven都需要自行配置。在jenkins中，對於編譯需要的環境，比如jdk，maven都可以在Web控制檯安裝即可。當然，jenkins也是可以自行配置的（有時候通過控制檯配置下載不下來）。
-

總結

在使用過兩者後，個人覺得gitlab-ci更簡單易用，如果有gitlab-ci達不到的要求，可以考慮使用jenkins。