背景：
1.Continuous Integration（持续集成）
假设一个应用程序，其代码存储在GitLab的Git仓库中。开发人员每天都要多次推送代码更改。对于每次向仓库的推送，你都可以创建一组脚本来自动构建和测试你的应用程序，从而减少了向应用程序引入错误的机会。这种做法称为持续集成，对于提交给应用程序（甚至是开发分支）的每项更改，它都会自动连续进行构建和测试，以确保所引入的更改通过你为应用程序建立的所有测试，准则和代码合规性标准。
2.Continuous Delivery（持续交付）
持续交付是超越持续集成的更进一步的操作。应用程序不仅会在推送到代码库的每次代码更改时进行构建和测试，而且，尽管部署是手动触发的，但作为一个附加步骤，它也可以连续部署。此方法可确保自动检查代码，但需要人工干预才能从策略上手动触发以必输此次变更。
3.Continuous Deployment（持续部署）
与持续交付类似，但不同之处在于，你无需将其手动部署，而是将其设置为自动部署。完全不需要人工干预即可部署你的应用程序。
CI（Continuous Integration）
在项目开展的过程中，我经常做功能分支-测试分支-部署分支之间的代码合并工作，虽然说我们团队有着合理的 Git Flow、Commit 规范，但确保不了每个开发人员在每次提交的时候都严格遵守，且在分支复杂、提交时间节点不确定的情况下，合并分支时产生冲突、处理冲突似乎成了不可避免的事，从开发的整个生命周期来看对产出效率的影响是不小的。
「工程化」还要考量的一个角度便是生产效率，也就是「自动化」，任何重复次数多于两次的简单机械劳动都应该交给机器来完成，这也就是前端工程化中“自动化”的过程，当然，不止前端了，任何需要频繁交付应用的团队都希望有一个工具、一种方法能应对“集成地狱”和机械化的部署工作。
CI
Continuous Integration，持续集成。集成这个动作指软件开发过程中合并代码的过程，而持续集成指的就是我们需要的自动化的过程——在开发人员提交新代码后，自动进行构建、测试、合并代码到代码仓库中。
ci的流程：
- 每次推送更改时，Git 服务器都会向 CI 服务器发送一个通知；
- CI 服务器克隆存储库，检出分支，并与主分支合并；
- 然后启动构建脚本；
- 如果返回 Code 为 0，则表示构建成功。否则，被视为失败；
- CI 服务器将带有构建结果的请求发送到 Git 服务器；
- 如果构建成功，则允许合并请求。否则，合并被阻止；
当我们在谈论 CI 时，我们在谈论什么
CI(Continuous Integration)，即持续集成，指频繁地（一天多次）将代码集成到主干的行为。 注意，这里既包含持续将代码集成到主干的含义，也包含持续将源码生成可供实际使用的制品的过程。因此，我们需要通过 CI，自动化地保证代码的质量，并对其构建产物转换生成可用制品供下一阶段调用。 因此，在 CI 阶段，我们至少有如下阶段需要实现：
- 静态代码检查 这其中包括，ESLINT/TSLINT 静态语法检查，验证 git commit message 是否符合规范，提交文件是否有对应 owner 可以 review 等等。这些静态检查不需要编译过程，直接扫描源代码就可以完成。
- 单元测试/集成测试/E2E 测试 自动化测试这一环节是保障制品质量的关键。测试用例的覆盖率及用例质量直接决定了构建产物的质量，因此，全面且完善的测试用例也是实现持续交付的必备要素。
- 编译并整理产物 在中小型项目中，这一步通常会被直接省略，直接将构建产物交由部署环节实现。但对于大型项目来说，多次频繁的提交构建会产生数量庞大的构建产物，需要得到妥善的管理
总而言之，持续集成主要要按照本地和远程服务器来划分，主要要做两件事情，一个是本地的eslint和git lint检查，另一个就是CI服务器要做的事：自动帮我们执行代码的构建、测试。为后期直接拿构建好的文件部署做准备。（这里ci开始执行构建一般表现在：我们将代码本地合并到test分支，然后push到远端的test仓库之后，ci服务器开始执行ci操作：test、build。而当我们想要合并master分支的时候，会比较严谨，提交pr后会开启备份预先跑一下CI，试一下合并后能否test、build，如果不成功则不可以合并，打回pr修改好冲突等重新提交pr，如果成功则允许合并，合并后开始真正的test、build）
参考文献：www.cnblogs.com/tencent-clo…
行业中相应的CI/CD的工具有很多，其中使用比较多的如：Jenkins、Gitlab CI/CD
jenkins对应的ci配置参考：blog.csdn.net/u013060778/…
CICD 在gitlab上的实现
CI/CD 是 GitLab 的内置工具，不需要第三方工具就可以拿来即用。GitLab CI/CD 会根据用户创建的特定 YAML 文件使用 GitLab Runner 自动执行脚本，文件中的脚本即是我们需要执行的操作，如添加依赖项、构建、单元测试等等。
中心思想是当每一次push到gitlab的时候，都会触发一次脚本执行，然后脚本的内容包括了测试，编译，部署等一系列自定义的内容。而gitlab-runner 是 gitlab 提供的持续集成工具。
1.下载gitlab-ce（gitlab产品被拆为：gitlab-ce社区版和gitlab-ee企业版）
下载命令：doceker pull gitlab/gitlab-ce
2.配置gitlab：
sudo docker run -d \
--plateform linux/386
--hostname xxx.gitlab.com \
--name gitlab \
--restart always \
--publish 22:22 --publish 80:80 --publish 443:443 \
--volume /Users/xxx/gitlab/config:/etc/gitlab \
--volume /Users/xxx/gitlab/logs:/var/log/gitlab \
--volume /Users/xxx/gitlab/data:/var/opt/gitlab \
gitlab/gitlab-ce:latest
注意：这里因为gitlab镜像是要求AMD64，所以需要加上
3.登录 gitlab
4.注册 gitlab 账号
5.配置SSH-KEY
6.搭建仓库
参考文献：gengjian1203.github.io/2021/01/23/…
gitlab 执行 CI/CD 的工作流程
为了使用GitLab CI/CD，你需要一个托管在GitLab上的应用程序代码库，并且在根目录中的.gitlab-ci.yml文件中指定构建、测试和部署的脚本。 在这个文件中，你可以定义要运行的脚本，定义包含的依赖项，选择要按顺序运行的命令和要并行运行的命令，定义要在何处部署应用程序，以及指定是否 要自动运行脚本或手动触发脚本。 为了可视化处理过程，假设添加到配置文件中的所有脚本与在计算机的终端上运行的命令相同。 一旦你已经添加了.gitlab-ci.yml到仓库中，GitLab将检测到该文件，并使用名为GitLab Runner的工具运行你的脚本。该工具的操作与终端类似。
gitlab runner
gitlab runer是执行CICD的工具，通俗点来说它就是用来执行gitlab上的CI/CD任务的机器（gitlab通过gitlab runner来支持cicd的）。gitlab runner可以通过npm或者docker安装，安装之后需要对runner进行配置，并且注册到gitlab服务器上。 项目中的.gitlab-ci.yml文件则是用来对runner任务进行管理的配置文件，在.gitlab-ci.yml文件中配置runner在ci各个阶段需要执行的具体任务。
xuezenghui.com/posts/gitla…) GitLab CI/CD 实践
参考文献：
www.cnblogs.com/cjsblog/p/1…
xuezenghui.com/posts/gitla…
重要理解文献：juejin.cn/post/687032…
