简介

CICD 是 持续集成（Continuous Integration）持续交付和持续部署（Continuous Deployment）简称。指在开发过程中自动执行一系列从开发到部署的过程中，尽量减少人工的介入。

CI

持续集成
​ 定义：频繁地(一天多次)将代码集成到主干。CI是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案，CI 主要针对在集成新代码时所引发的问题（亦称“集成地狱”）。

​ 持续集成强调开发人员提交了新代码之后，立刻自动的进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。

持续集成的目的:
就是让产品可以快速迭代，同时还能保持高质量**。**它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。

​ 持续集成过程中很重视自动化测试验证结果，对可能出现的一些问题进行预警，以保障最终合并的代码没有问题。

持续集成的作用:
代码库存越是积压，就越得不到生产检验，积压越多，代码间交叉感染的概率越大，下个发布（release）的复杂度和风险越高，持续集成可以保证团队开发人员提交代码的质量，减轻了软件发布时的压力；
持续集成中的任何一个环节都是自动完成的，无需太多的人工干预，有利于减少重复过程以节省时间、费用和工作量；
及早的发现代码中的问题，及早解决，代码越早推送（PUSH）出去，用户能越早用到，快就是商业价值；
特点

它是一个自动化的周期性的集成测试过程，从检出代码、编译构建、运行测试、结果记录、测试统计等都是自动完成的，无需人工干预；
需要有专门的集成服务器来执行集成构建；
需要有代码托管工具支持；

CD

CI/CD 中的“CD”指的是持续交付和/或持续部署，这些相关概念有时会交叉使用。两者都事关管道后续阶段的自动化，但它们有时也会单独使用，用于说明自动化程度。

​ 持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。

​ 持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。持续交付通常是指开发人员对应用的更改会自动进行错误测试并上传到存储库（如 GitHub或容器注册表），然后由运维团队将其部署到实时生产环境中。这旨在解决开发和运维团队之间可见性及沟通较差的问题。因此，持续交付的目的就是确保尽可能减少部署新代码时所需的工作量。

​ 持续部署（另一种“CD”）指的是自动将开发人员的更改从存储库发布到生产环境，以供客户使用。它主要为了解决因手动流程降低应用交付速度，从而使运维团队超负荷的问题。持续部署以持续交付的优势为根基，实现了管道后续阶段的自动化。

​ 归根结底，我们没必要纠结于这些语义，您只需记得 CI/CD 其实就是一个流程（通常形象地表述为管道），用于实现应用开发中的高度持续自动化和持续监控。因案例而异，该术语的具体含义取决于 CI/CD 管道的自动化程度。许多企业最开始先添加 CI，然后逐步实现交付和部署的自动化（例如作为[云原生应用]的一部分）。

CICD实现过程
工厂里的装配线以快速、自动化、可重复的方式从原材料生产出消费品。同样，软件交付管道以快速、自动化和可重复的方式从源代码生成发布版本。如何完成这项工作的总体设计称为“持续交付”（CD）。启动装配线的过程称为“持续集成”（CI）。确保质量的过程称为“持续测试”，将最终产品提供给用户的过程称为“持续部署”

实现流程

​ 1、运维管理员创建gitlab项目，创建Jenkins项目

​ 2、开发人员将code提交到对应的gitlab中（可按分支触发）

​ 3、gitlab通过webhook触发对应Jenkins项目

​ 4、进入CI环节：将code集成进标准的docker镜像中，并进行测试；

​ 集成及测试成功，则将集成后的镜像上传至仓库中；

集成或测试失败，则结束本次Jenkins，并将原因通过邮件发送给开发者与运维管理员。

​ 5、进入CD环节：

​ 通过Ansible将CI集成成功的镜像部署到已定义的所有机子中，并进行测试。

​ 如测试通过完成本次部署，如测试失败将判定该项目是否为第一次部署的；

​ 如该项目不是第一次部署的，则滚回到上一版本的容器，并将原因通过邮件发送给运维管理员。

如测试失败将判定该项目是否为第一次部署的；

​ 如该项目不是第一次部署的，则滚回到上一版本的容器，并将原因通过邮件发送给运维管理员。

CI
1.首先是开发人员写相应的代码（写好之后就把代码提交到gitlub上面去）
2.写完代码之后然后再打包
3.打包完成之后，然后再部署。
4.发布完成之后然后就是测试人员测试
（开发、和测试用的，就算用奔溃了可以重新再部署一个）
（它不适用生产环境，因为有客户在使用）

CD
持续交互
5.测试人员测试没有任何问题之后，然后就把他放到代码仓库里面去（把它放到docker里面去，把它打包成一个docker镜像）
持续部署
从刚刚放到docker里面的一个镜像把它拉到生产环境里面去部署
6.持续部署我们应该人为发布，不能CICD自动化发布，因为我们不知道什么时候要发布，我们必须得到一个精确的发布时间，然后要走流程，流程通过之后我们再手动发布，所有我们的持续部署要用手动发布。