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