目录

CI & CD 概述：

持续集成概述：

1.软件开发生命周期：

需求分析：

设计：

实现：

测试：

进化：

2.软件开发瀑布模型：

3.软件敏捷开发：

4.持续集成概述：

持续集成的流程：

持续集成的组成元素：

持续集成优势：

CI 持续集成（Continuous Integration）

CD 持续交付（Continuous Delivery）

CD 持续部署（Continuous Deployment）

---

CI & CD 概述：

        CI & CD：是通过在应用开发阶段引入自动化来频繁向客户交付应用的方法，CI & CD的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运行团队的解决方案，CI&CD主要针对在集成新代码时所引发的问题（集成地狱）。

        具体而言，CI&CD可以持续自动化和持续监控贯穿于整个生命周期（从集成和测试阶段，到交付和部署）。这些关联的事务通常被统称为”CI&CD管道“，由开发和运营团队以敏捷方式协同部署。

---

持续集成概述：

1.软件开发生命周期：

        软件开发生命周期又叫SDLC（Software Development Life Cycle），它集合了计划、开发、测试和部署过程的集合。

需求分析：

        这是生命周期的第一阶段，根据项目需求，团队执行一个可行性计划的分析。项目需求可能是公司内部或者客户提出的。这阶段主要是对信息的收集，也有可能是对现有的项目的改善和重新做一个新的项目。还要分析项目的预算多长，可以从哪些方面受益及布局，这也是项目创建的目标。

设计：

        第二阶段就是设计阶段，系统架构和满意状态（就是要做成什么样子，有什么功能），和创建一个项目计划。计划可以使用图表，布局设计或者文者的方式呈现。

实现：

        第三阶段就是实现阶段，项目经理创建和分配工作给开发者，开发者根据任务和在设计阶段定义的目标进行开发代码。依据项目的大小和复杂程度，可以需要数月或更长时间才能完成。

测试：

        测试人员进行代码测试，包括功能测试、代码测试、压力测试等。

进化：

        最后阶段就是对产品不断的进化和维护阶段，根据用户的使用情况，可能需要对某功能进行修改，bug修复，功能增加等。

2.软件开发瀑布模型：

        瀑布模型是最著名和最常用的软件开发模型。瀑布模型就是一系列的软件开发过程。它是由制造业衍生出来的。一个高度结构化流程在一个方向上流动，有点像生产线一样。在瀑布模型创建之初，没有其他开发的模型，很多东西全靠开发人员去猜测，去开发。这样的模型仅适用于那些简单的软件开发，但是已经不适合现在的开发模式。

3.软件敏捷开发：

        敏捷开发（Agile Development）的核心是迭代开发（Iterative Development）与增量开发（Incremental Development）。

---

4.持续集成概述：

        持续集成（continuous integration，简称CI）指的是，频繁的（一天多次）将代码集成到主干。持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。他的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。

持续集成的流程：

1. 提交：流程的第一步，是开发者向代码仓库提交代码。所有后面的步骤都是始于本地代码的第一次提交（commit）
2. 测试（第一轮）：代码仓库对commit操作配置了钩子（hook），只要提交了代码或者合并进主干，就会开启自动化测试。
3. 构建：通过第一轮测试，代码就可以合并进主干，就算可以交付了。交付后，就先进行构建（build），再进行第二轮测试，所谓构建，指的是将源代码转化为可以运行的实际代码，比如安装依赖，配置各种资源（样式表，JS脚本，图片）等等。
4. 测试（第二轮）：构建完成，就要进行第二轮测试。如果第一轮已经覆盖了所有的测试内容，那么第二轮测试可以省略，当然，这时候构建步骤也要转移到第一轮测试之前。
5. 部署：通过第二轮测试，当前代码是一个可以直接部署的版本（artifact），将这个版本的所有文件打包（tar filename.tar*）存档，发送到生产服务器。
6. 回滚：一旦当前版本发生问题，就要回滚到上一个版本的构建结果，最简单的做法就是修改一下符号链接，指向上一个版本目录。

持续集成的组成元素：

• 一个自动构建过程，从检查代码、编译构建、运行测试、结果记录、测试统计等都是自动完成的，无需人工干预。
• 一个代码存储库，既需要版本控制软件来保证代码的可维护性，同时作为构建过程的素材库，一般使用SVN或者Git
• 一个持续集成服务器，Jenkins就是一个配置简单和使用方便的持续集成服务器。

 

持续集成优势：

• 降低风险，由于持续集成不断去构建、编译、测试，可以很早发现问题，减少修复代价。
• 对系统健康持续检查，减少发布带来的风险问题
• 减少重复性工作
• 持续部署，提供可部署单元包

---

CI 持续集成（Continuous Integration）

        现代应用开发的目标是让多位开发人员同时处理同一应用的不同功能。但是，如果企业安排在一天内将所有分支源代码合并在一起（称为合并日），最终可能造成工作繁项、耗时，而且需要手动完成。这是因为当一位独立工作的开发人员对应用进行更改时，有可能会与其他开发人员同时进行的更改发生冲突。如果每个开发人员都自定义自己的本地集成开发环境（IDE），而不是让团队就一个基于云的IDE达成一致，那么就会让问题更加雪上加霜。

        持续集成（CI）可以帮助开发人员更加频繁地（有时甚至每天）将代码更改合并到共享分支或主干中。一旦开发人员对应用所做的更改被合并，系统就会通过自动构建应用并运行不同级别的自动化测试（通常是单元测试和集成测试）来验证这些更改，确保这些更改没有对应用造成破坏。这意味着测试内容涵盖了从类和函数到构成整个应用的不同模块。如果自动化测试发现新代码和现有代码之间存在冲突，CI可以更加轻松地快速修复这些错误。

CD 持续交付（Continuous Delivery）

        完成CI中构建及单元测试和集成测试的自动化流程后，持续交付可自动将已验证的代码发布到存储库。为了实现高效的持续交付流程，务必要确保CI已内置于开发管道。持续交付的目标是拥有一个可随时部署到生产环境的代码库。在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都涉及测试自动化和代码发布自动化，在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中。

CD 持续部署（Continuous Deployment）

        对于一个成熟的CI/CD管道来说，最后的阶段是持续部署。作为持续交付一自动将生产就绪型构建版本发布到代码存储库-的延伸，持续部署可以自动将应用发布到生产环境。由于在生产之前的管道阶段没有手动门控，因此持续部署在很大程度上都得依赖精心设计的测试自动化。
        实际上，持续部署意味着开发人员对应用的更改在编写后的几分钟内就能生效（假设它通过了自动化测试）。这更加便于持续接收和整合用户反馈。总而言之，所有这些CI/CD的关联步骤都有助于降低应用的部署风险，因此更便于以小件的方式（而非一次性）发布对应用的更改。不过，由于还需要编写自动化测试以适应CI/CD管道中的各种测试和发布阶段，因此前期投资还是会很大。