# 关于CI/CD
CI/CD 具有不同的含义, "CI"始终指持续集成，它属于开发人员的自动化流程。"CD"指的是持续交付和/或持续部署，这些相关概念有时会交叉使用。在现在的devops模式下，可以使用ci/cd持续集成对项目进行部署，通过，ci/cd中的一些环境变量则可以区分出对应的环境，以便于软件开发流程的控制。

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

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

> 现有的CI工具则有
> - gitee (码云)
> - GitHub
> - gitlab (企业内部仓库)
> - gitea (轻量化代码仓库)

## CD 持续部署（Continuous Deployment）
对于一个成熟的 CI/CD 管道来说，最后的阶段是持续部署。作为持续交付——自动将生产就绪型构建版本发布到代码存储库——的延伸，持续部署可以自动将应用发布到生产环境。由于在生产之前的管道阶段没有手动门控，因此持续部署在很大程度上都得依赖精心设计的测试自动化。

实际上，持续部署意味着开发人员对应用的更改在编写后的几分钟内就能生效（假设它通过了自动化测试）。这更加便于持续接收和整合用户反馈。总而言之，所有这些 CI/CD 的关联步骤都有助于降低应用的部署风险，因此更便于以小件的方式（而非一次性）发布对应用的更改。不过，由于还需要编写自动化测试以适应 CI/CD 管道中的各种测试和发布阶段，因此前期投资还是会很大。

> 现有的CD工具
> - jekenis (主流)
> - drone (小众轻量化)
> - gitlab (自带cd环境,需要配置一台外部的ranner执行构建任务)

## 集群部署环境k8s
Kubernetes是Google 2014年创建管理的，是Google 10多年大规模容器管理技术Borg的开源版本。它是容器集群管理系统，是一个开源的平台，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。

在开发过程中，大多时候开发人员或运维人员并不会使用Kubernetes client 命令行工具，更多的是使用Kubernetes的可视化管理界面。
> - kuboard
> - Lens
> - KubeSphere
> - Wayne
> - Kubernetes Dashboard
> - Rancher

Kubernetes在应对分布式,集群管理的情况下可谓是的心应手。


## 完整的CI/CD组合
完整的ci/cd组合,即ci工具+cd工具联通,实现持续集成与持续部署的功能
- gitee + jekenis + k8s
- gitlab + jekenis + k8s
- gitea + jekenis + k8s
- gitea + drone + k8s

## 系统ci/cd
本系统由于资源紧张则选用轻量化的组合,gitea+drone+k8s(rancher)
下面会介绍每个组件的相关安装以及如何运用于本系统。
另外，如需要参考ci/cd运用于其他的单体项目则可以参考

[Gitea+Drone+Rancher CI/CD持续集成解决方案](https://blog.odliken.cn/2022/08/07/giteadronerancher-ci-cd%e6%8c%81%e7%bb%ad%e9%9b%86%e6%88%90%e8%a7%a3%e5%86%b3%e6%96%b9%e6%a1%88/)