Gitlab定义
持续集成，持续发布，持续部署是DevOps中三个实现手段很相似，但是应用场景不同的三个概念。我接下来主要从应用场景来描述一下这三个场景的主要关注点。
持续集成：
发生在开发阶段，开发人员每天都需要push代码到代码仓库，有时候每天会push很多次。每次开发人员push代码到仓库中是，我们希望通过持续集成pipeline脚本，帮助开发人员发现提交代码中的错误。
所以持续集成需要回答以下重要问题
1、开发人员每天push代码到哪个分支，什么时候push？
2、哪些工作应该在push之前在本地环境中完成并且解决，哪些在push到代码仓库后由持续集成脚本完成？
3、持续集成脚本发现错误后，如何反馈给开发人员，反馈周期是什么？
首先，持续集成必须和项目的分支模型有关，以下讨论目前github或者是gitlab最通用的一种工作模型：
首先我们为了实现一个功能，把能描述在一个issue里面（对应一个jira的user story，或者github或者gitlab上的一个issue）。
开发人员从issue上开始生成一个分支（分支的名字和issue关联）。
开发人员push代码到feature分支，持续集成pipeline执行。如果有错误，开发人员修复并在此推送，知道满足条件。
开发人员发起merge request， 合并到主分支。 在主分支触发持续部署流程。
这个模型的问题如下：
1、开发人员应该在push代码前，本地开发环境就能完成编译， 单元测试，静态代码检查等工作，在pipeline平台上完成只能起到监督的作用，也就是说，起到一些特别没有经验，或者说是特别没有责任心的让开发人员胡乱push代码的问题。因为理论上来讲，开发人员在本地完成将会更加方便有效。
2、在代码合并前review的时候起到检查作用。
3、开发人员如果频繁push代码，可能会对系统的持续集成能力产生大量压力。
4、适合这个阶段的检查点有： 代码规范扫描， 代码静态检查，代码开源协议检查，单元测试，代码编译打包
5、此阶段的代码编译打包有什么用处？
6、每个开发人员的开发环境可能不是标准的，push到代码仓库后，使用标准的环境进行编译，打包。