Git学习笔记9

Gitlab中的代码是要部署到生产服务器上。

CI：

Continuous integration 简称CI：

是一种软件开发实践，即开发团队成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化构建（包括编译、发布、自动化测试）来验证，从而尽快地发现集成中的错误。

构建：对代码进行编译、测试。

如果是人做的话，先是git clone，然后进行编译测试。

如果是自动化，那么就需要一台服务器来做。专门的服务器CI Server服务器（jenkins），自动将代码下载下来，自动进行编译、测试，自动结果反馈。

目的：

持续集成的目的不是减少build失败的次数，而是尽早地发现问题，在最短的时间内解决问题，减少风险和浪费。从而让产品开发流程更加敏捷，缩短产品开发周期，在产品上线后，让用户用的更加顺畅。

在没有应用持续集成之前，传统的开发模式是项目一开始就划分模块，每个开发人员分别负责一个模块，等所有的代码都开发完成之后再集成到一起提交给测试人员，随着软件技术团队的发展，软件已经不能简单地通过划分模块的方式来开发，需要项目内部相互协作，划分模块这种传统的模式的弊端也越来越明显。由于很多bug在项目早期的设计、编码阶段就引入，到最后集成测试时才发现问题，开发人员需要花费大量的时间来定位bug，加上软件的复杂性，bug的定位就更难了，甚至出现不得不调整底层架构的情况。这种情况的发生不仅仅对测试进度造成影响，而且会拖长整个项目周期。

而持续集成可以有效解决软件开发过程中的许多问题，在集成测试阶段之前就帮助开发人员发现问题，从而可以有效的确保软件质量，减小项目的风险，使软件开发团队从容的面对各种变化。持续集成报告中可以体现目前项目进度，哪部分需要已经实现，哪些代码已经通过自动化测试，代码质量如何，让开发团队和项目组了解项目的真实状况。

快速定位发现软件问题的开发实践。只要有代码更新，那么CI 服务器就自动pull下来，编译然后run下并进行测试。看看代码是否有问题。最终生成集成报告。

持续测试

Continuous Testing,简称CT

持续测试是贯穿着整个软件开发过程，验证程序员提交代码，检验合规性及降低bug,减少最终错误，实现敏捷及精益开发。

目的

1. 为了降低开发、部署、发布等可能出现的错误

2. 防止代码出错

3. 防止功能出错

4. 防止业务逻辑出错等

持续交付：CD：

持续交付（CD）：

持续交付是指软件开发过程，从原始需求到最终产品开发过程中，较短周期内以需求的小颗粒度（小批量）频繁提交的过程，主要是指集成后的代码在类生产环境（测试环境、预发布环境）中测试，并及时反馈的过程。

STAGING：测试环境或者预生产环境。环境版本都要保持一致。分毫不差。配置都要一样的。php7.2 和php7.3的问题，全部都一致。

自动化：系统都要一样的装。系统包都一样的。容器把环境打包。系统排除。

目的

1. 开发过程的快速迭代，小步快跑，及时纠正偏离主线

2. 小颗粒度实现，避免颗粒度大，出现问题解决麻烦

3. 迅速反馈软件功能，避免方向性错误

4. 团队角色（含客户）协作密切，减少时间浪费

达到这个程度就能理解。

Continuous Deployment，简称CD

基于持续交付的基础上，把功能稳定，符合产品需求的版本有方法地部署至生产环境中。可以看作是持续交付（CD）的最后一环。

代码直接部署上传到Web服务器（生产环境）。

持续发布

Continuous Release，简称CR

发布是周期性或不定期地对项目在部署后，进行整体软件版本的更新，例如，更新新功能或展示页面框架等。

目的

1. 产品的快速迭代，小步快跑

2. 适应市场变化

3. 匹配市场策略

4. 应对市场风险

这里适应市场变化、市场策略、市场风险，有点产品经理或者项目经理或者老板的决策因素在里面了。

部署和发布的区别：没有什么太大的区别。

发布某个App版本。部署：环境部署。

持续测试

Continuous Testing,简称CT

持续测试是贯穿着整个软件开发过程，验证程序员提交代码，检验合规性及降低bug,减少最终错误，实现敏捷及精益开发。

目的

1. 为了降低开发、部署、发布等可能出现的错误

2. 防止代码出错

3. 防止功能出错

4. 防止业务逻辑出错等

总结：

1）CI 持续集成：是一个快速定位或者发现软件缺陷的开发实践。

2）CD持续交付：把集成的代码交付给测试工程师进行测试，再交付给运维工程师在测试环境进行测试，最终上线到生产环境的一个过程。