GitLabCI VS Jenkins
Jenkins 是一個廣泛用於持續集成的可視化 web 自動化工具，jenkins 可以很好的支持各種語言的項目構建，也完全兼容ant、maven、gradle等多種第三方構建工具，同時跟svn、git能無縫集成，也支持直接與知名源代碼託管網站，比如github、bitbucket直接集成，而且插件衆多，在這麼多年的技術積累之後，在國內大部分公司都有使用Jenkins。
gitlab-CI是gitlab8.0之後自帶的一個持續集成系統，中心思想是當每一次push到gitlab的時候，都會觸發一次腳本執行，然後腳本的內容包括了測試，編譯，部署等一系列自定義的內容。
gitlab-CI的腳本執行，需要自定義安裝對應gitlab-runner來執行，代碼push之後，webhook檢測到代碼變化，就會觸發gitlab-CI，分配到各個Runner來運行相應的腳本script。這些腳本有的是測試項目用的，有的是部署用的。
差異點對比
分支的可配置性
- 使用GitLab CI，新創建的分支無需任何進一步配置即可立即使用CI管道中的已定義作業。
- Jenkins 2 基於gitlab的多分支流水線可以實現。相對配置來說gitlab更加方便一些。
定時執行構建
有時，根據時間觸發作業或整個管道會有所幫助。例如，常規的夜間定時構建。
-
使用Jenkins 2可以立即使用。可以在應執行作業或管道的那一刻以cron式語法定義。
-
GitLab CI沒有此功能。但是，可以通過一種變通辦法來實現：通過WebAPI使用同一臺或另一臺服務器上的cronjob觸發作業和管道。
儘管使用GitLab CI無法做到這一點，其實如果配置了提交代碼即觸發流水線，那麼最後一次提交的構建在什麼時候沒有什麼不同，反而減少未提交代碼的定時構建資源浪費。
拉取請求支持
如果很好地集成了存儲庫管理器和CI / CD平臺，您可以看到請求的當前構建狀態。使用這種功能，可以避免將代碼合併到不起作用或無法正確構建的主分支中。
- Jenkins沒有與源代碼管理系統進一步集成，需要管理員自行寫代碼或者插件實現。
- GitLab與其CI平臺緊密集成，可以方便查看每個打開和關閉拉動請求的運行和完成管道。
權限管理
從存儲庫管理器繼承的權限管理對於不想爲每個服務分別設置每個用戶的權限的大型開發人員或組織團體很有用。大多數情況下，兩種情況下的權限都是相同的，因此默認情況下應將它們配置在一個位置。
-
由於GitLab與GitLabCI的深度整合，權限可以統一管理。
-
由於Jenkins 2沒有內置的存儲庫管理器，因此它無法直接在存儲庫管理器和CI / CD平臺之間合併權限。
存儲庫交互
- GitLab CI是Git存儲庫管理器GitLab的固定組件，因此在CI / CD流程和存儲庫功能之間提供了良好的交互。
- Jenkins 2與存儲庫管理器都是鬆散耦合的，因此在選擇版本控制系統時它非常靈活。此外，就像其前身一樣，Jenkins 2強調了對插件的支持，以進一步擴展或改善軟件的現有功能。
插件管理
- 擴展Jenkins的本機功能是通過插件完成的。插件的維護，保護和升級成本很高。
- GitLab是開放式的，任何人都可以直接向代碼庫貢獻更改，一旦合併，它將自動測試並維護每個更改。
優勢與劣勢
GitLabCI
- 輕量級，不需要複雜的安裝手段。
- 配置簡單，與
gitlab可直接適配。 - 實時構建日誌十分清晰，
UI交互體驗很好 -
使用
YAML進行配置，任何人都可以很方便的使用。 -
沒有統一的管理界面，無法統籌管理所有項目
-
配置依賴於代碼倉庫，耦合度沒有
Jenkins低
Jenkins
- 編譯服務和代碼倉庫分離，耦合度低
- 插件豐富，支持語言衆多。
- 有統一的
web管理界面。 - 插件以及自身安裝較爲複雜。
- 體量較大，不是很適合小型團隊。
實際應用
- GitLabCI 有助於DevOps人員，例如敏捷開發中，開發與運維是同一個人，最便捷的開發方式。
- JenkinsCI適合在多角色團隊中，職責分明、配置與代碼分離、插件豐富。
一起學習呀：
