Gitlab中的代码是要部署到生产服务器上。
CI：
Continuous integration 简称CI：
是一种软件开发实践，即开发团队成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化构建（包括编译、发布、自动化测试）来验证，从而尽快地发现集成中的错误。
构建：对代码进行编译、测试。
如果是人做的话，先是git clone，然后进行编译测试。
如果是自动化，那么就需要一台服务器来做。专门的服务器CI Server服务器（jenkins），自动将代码下载下来，自动进行编译、测试，自动结果反馈。
目的：
持续集成的目的不是减少build失败的次数，而是尽早地发现问题，在最短的时间内解决问题，减少风险和浪费。从而让产品开发流程更加敏捷，缩短产品开发周期，在产品上线后，让用户用的更加顺畅。
在没有应用持续集成之前，传统的开发模式是项目一开始就划分模块，每个开发人员分别负责一个模块，等所有的代码都开发完成之后再集成到一起提交给测试人员，随着软件技术团队的发展，软件已经不能简单地通过划分模块的方式来开发，需要项目内部相互协作，划分模块这种传统的模式的弊端也越来越明显。由于很多bug在项目早期的设计、编码阶段就引入，到最后集成测试时才发现问题，开发人员需要花费大量的时间来定位bug，加上软件的复杂性，bug的定位就更难了，甚至出现不得不调整底层架构的情况。这种情况的发生不仅仅对测试进度造成影响，而且会拖长整个项目周期。
而持续集成可以有效解决软件开发过程中的许多问题，在集成测试阶段之前就帮助开发人员发现问题，从而可以有效的确保软件质量，减小项目的风险，使软件开发团队从容的面对各种变化。持续集成报告中可以体现目前项目进度，哪部分需要已经实现，哪些代码已经通过自动化测试，代码质量如何，让开发团队和项目组了解项目的真实状况。
快速定位发现软件问题的开发实践。只要有代码更新，那么CI 服务器就自动pull下来，编译然后run下并进行测试。看看代码是否有问题。最终生成集成报告。
持续测试
Continuous Testing,简称CT
持续测试是贯穿着整个软件开发过程，验证程序员提交代码，检验合规性及降低bug,减少最终错误，实现敏捷及精益开发。
目的
-
为了降低开发、部署、发布等可能出现的错误
-
防止代码出错
-
防止功能出错
-
防止业务逻辑出错等
持续交付：CD：
持续交付（CD）：
持续交付是指软件开发过程，从原始需求到最终产品开发过程中，较短周期内以需求的小颗粒度（小批量）频繁提交的过程，主要是指集成后的代码在类生产环境（测试环境、预发布环境）中测试，并及时反馈的过程。
STAGING：测试环境或者预生产环境。环境版本都要保持一致。分毫不差。配置都要一样的。php7.2 和php7.3的问题，全部都一致。
自动化：系统都要一样的装。系统包都一样的。容器把环境打包。系统排除。
目的
-
开发过程的快速迭代，小步快跑，及时纠正偏离主线
-
小颗粒度实现，避免颗粒度大，出现问题解决麻烦
-
迅速反馈软件功能，避免方向性错误
-
团队角色（含客户）协作密切，减少时间浪费
达到这个程度就能理解。
Continuous Deployment，简称CD
基于持续交付的基础上，把功能稳定，符合产品需求的版本有方法地部署至生产环境中。可以看作是持续交付（CD）的最后一环。
代码直接部署上传到Web服务器（生产环境）。
持续发布
Continuous Release，简称CR
发布是周期性或不定期地对项目在部署后，进行整体软件版本的更新，例如，更新新功能或展示页面框架等。
目的
-
产品的快速迭代，小步快跑
-
适应市场变化
-
匹配市场策略
-
应对市场风险
这里适应市场变化、市场策略、市场风险，有点产品经理或者项目经理或者老板的决策因素在里面了。
部署和发布的区别：没有什么太大的区别。
发布某个App版本。部署：环境部署。
持续测试
Continuous Testing,简称CT
持续测试是贯穿着整个软件开发过程，验证程序员提交代码，检验合规性及降低bug,减少最终错误，实现敏捷及精益开发。
目的
-
为了降低开发、部署、发布等可能出现的错误
-
防止代码出错
-
防止功能出错
-
防止业务逻辑出错等
总结：
1）CI 持续集成：是一个快速定位或者发现软件缺陷的开发实践。
2）CD持续交付：把集成的代码交付给测试工程师进行测试，再交付给运维工程师在测试环境进行测试，最终上线到生产环境的一个过程。
＞ func_t；)
