http://blog.csdn.net/xinluke/article/details/53982150
Jenkins
Jenkins作為老牌的持續集成框架，在這么多年的發展中，積累很多優秀的plugin工具，對進行持續集成工作帶來很大的便利。
gitlab-ci作為gitlab提供的一個持續集成的套件，完美和gitlab進行集成，gitlab-ci已經集成進gitlab服務器中，在使用的時候只需要安裝配置gitlab-runner即可。
gitlab-runner基本上提供了一個可以進行編譯的環境，負責從gitlab中拉取代碼，根據工程中配置的gitlab-ci.yml，執行相應的命令進行編譯。
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。
