使用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

(adsbygoogle = window.adsbygoogle || []).push({});