CI/CD介绍

CI/CD介绍

CI/CD介绍

软件开发的持续方法基于自动执行脚本，以最大程度地减少在开发应用程序时引入错误的机会。从开发新代码到部署新代码，他们几乎不需要人工干预，甚至根本不需要干预。

它涉及到在每次小的迭代中就不断地构建、测试和部署代码更改，从而减少基于已经存在bug或失败的先前版本开发新代码的机会。

Continuous Integration(持续集成)

假设一个应用程序，其代码存储在GitLab的Git仓库中。开发人员每天都要多次推送代码更改。对于每次向仓库的推送，你都可以创建一组脚本来自动构建和测试你的应用程序，从而减少了向应用程序引入错误的机会。这种做法称为持续集成，对于提交给应用程序(甚至是开发分支)的每项更改，它都会自动连续进行构建和测试，以确保所引入的更改通过你为应用程序建立的所有测试，准则和代码合规性标准。

Continuous Delivert(持续交付)

持续交付是超越持续集成的更进一步的操作。应用程序不仅会在推送到代码库的每次代码更改时进行构建和测试，而且，尽管部署是手动触发的，但作为一个附加步骤，它也可以连续部署。此方法可确保自动检查代码，但需要人工干预才能从策略上手动触发以部署此次变更。

Continuous Deployment(持续部署)

与持续交付类似，但不同之处在于，你无需将其手动部署，而是将其设置为自动部署。完全不需要人工干预即可部署你的应用程序。

CI/CD工作流程

1. 运维人员创建gitlab项目，创建Jenkins项目

2. 开发人员将code提交到对应的gitlab中(可按分支触发)

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

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

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

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

5. 进入CD环节：

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

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

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