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持续交付:把集成的代码交付给测试工程师进行测试,再交付给运维工程师在测试环境进行测试,最终上线到生产环境的一个过程。