持续集成简介
本文简单介绍 持续集成 的概念，并对 GitLab CI 持续集成环境进行简要介绍，后续将基于搭建基于Docker的 GitLab CI 环境配置，对具体的配置步骤和使用进行更详细的介绍。
什么是持续集成？
持续集成（Continuous Integration，简称CI）指的是，频繁地（一天多次）将代码集成到主干(master)。
持续集成的好处
快速发现错误
每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易
防止分支大幅偏离主干
如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。
持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是， 代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。
持续交付、持续部署的概念
持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。
持续部署（continuous deployment）是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。
持续集成的原则
业界普遍认同的持续集成的原则如下：
-
需要版本控制软件保障团队成员提交的代码不会导致集成失败。常用的版本控制软件有 git、svn 等;
-
开发人员必须及时向版本控制库中提交代码，也必须经常性地从版本控制库中更新代码到本地；
-
需要有专门的集成服务器来执行集成构建。根据项目的具体实际，集成构建可以被软件的修改来直接触发，也可以定时启动，如每半个小时构建一次；
-
必须保证构建的成功。如果构建失败，修复构建过程中的错误是优先级最高的工作。一旦修复，需要手动启动一次构建。
持续集成系统的组成
一个完整的构建系统必须包括：
-
一个自动构建过程，包括自动编译、分发、部署和测试等；
-
一个代码存储库，即需要版本控制软件来保障代码的可维护性，同时作为构建过程的素材库；
-
一个持续集成服务器。
GitLab CI 简介
GitLab CI是 GitLab 提供的持续集成服务，只要在你的仓库根目录 创建一个.gitlab-ci.yml 文件， 并为该项目指派一个Runner，当有合并请求或者 push的时候就会触发build。
这个.gitlab-ci.yml 文件定义GitLab runner要做哪些操作。 默认有3个[stages(阶段)]: build、test、deploy。
当build完成后(返回非零值)，你会看到push的 commit或者合并请求前面出现一个绿色的对号。 这个功能很方便的让你检查出来合并请求是否会导致build失败， 免的你去检查代码。
大部分项目用GitLab’s CI服务跑build测试， 开发者会很快得到反馈，知道自己是否写出了BUG。
要让CI工作必须具备的条件是：
-
在仓库根目录创建一个名为.gitlab-ci.yml 的文件;
-
为项目配置一个Runner。
完成上面的步骤后，每次push代码到Git仓库， Runner就会自动开始pipeline。
基于Docker的GitLab CI 持续集成环境搭建
ToDo。后续将基于Docker搭建一个GitLab的CI持续集成环境，具体配置步骤及使用说明待搭建配置完成后再开一篇进行描述。