使用Gitlab和Gitlab CI作持續集成（理論篇）

持續集成是一種軟件開發實踐。

在持續集成中，團隊成員頻繁集成他們的工做成果，通常每人天天至少集成一次，也能夠屢次。

每次集成會通過自動構建（包括自動測試）的檢驗，以儘快發現集成錯誤。

關於持續集成，能夠閱讀Martin Fowler（馬丁·福勒 ）的經典文章：http://www.martinfowler.com/articles/continuousIntegration.html

 

集成的頻率越高越好，更頻繁的集成意味着更早的發現問題。

經過持續集成，及時發現和解決代碼故障，提升代碼質量，減小故障處理成本等等。

 

當下持續集成工具不勝枚舉，開源的或商業的，可本地安裝的或Sass的，如：

• 當前最最流行的，一騎絕塵的Jenkins
• 與Github緊密集成的Travis CI
• 有着持續集成DNA的ThoughtWorks GO
• Atlassian工具鏈之一的Bamboo
• 與Gitlab緊密集成的Gitlab CI
• ……

持續集成工具技術選型（Jenkins VS Gitlab CI）：

• Jenkins有GUI
  • GUI使得易於學習與使用，但一系列插件可能會變得混亂不堪
  • 若是須要用戶訪問與管理，這個是首選
• 與Gitlab的集成，Jenkins不及Gitlab CI
  • Jenkins須要爲Project建立JOB，commit與build對應關係沒法直觀體現
  • Gitlab8.0版本開始徹底集成了持續集成工具Gitlab CI
  • Gitlab CI有漂亮的界面，每一個構建有跡可循，偏於回溯
• 使用yaml定義Build Pipeline更清晰
  • 使用yaml定義Pipeline的CI產品
    • Travis CI
    • Bitbucket Pipelines
    • Circle CI
    • Magnum CI
• Jenkins2.0也支持更高級的Pipeline
  • 使用Jenkinsfile和Pipeline插件，Jenkinsfile 使用Groovy DSL定義
• Pipeline、Stage、Job的概念相似ThoughtWorks GO中的概念
  • 一個pipeline包含一個或多個stage，stage是串行的
  • 一個stage包含一個或多個job，job是並行的

 

鑑於Gitlab CI與Gitlab集成的更友好，並且想嘗試下Gitlab CI + Docker，因而選擇了Gitlab CI作持續集成。

 

使用Gitlab CI進行持續集成實踐的流程：

• 代碼Check In到GitLab
• 提交後觸發Gitlab CI（使用Docker進行Build）
• Gitlab CI 拉取代碼進行編譯、質量分析（SonarQube ）
• SonarQube 將質量分析報告反饋到GitLab相應的commit（以Comment的形式）
• Gitlab將構建結果反饋給Develop （以Email的形式 ）

 

參考：

https://about.gitlab.com/gitlab-ci/

http://stackoverflow.com/questions/37429453/gitlab-ci-vs-jenkins

https://about.gitlab.com/2016/07/22/building-our-web-app-on-gitlab-ci/

https://insights.sei.cmu.edu/devops/2015/01/continuous-integration-in-devops-1.html