一、背景
随着业务不断发展项目变得日益增多，项目集成、 部署的过程变得频繁、漫长、复杂且不统一，不利于问题在第一时间被发现和解决，人工操作带来效率低下的同时也更易出现错误甚至故障。
所以为解决上述问题，需要设计一套项目组通用的持续集成与部署方案。
二、名称定义
| 名称 | 描述 |
|---|---|
| 持续集成（Continuous integration，简称CI） | 频繁地将代码集成到主干 |
| 持续交付（Continuous delivery） | 频繁地将软件的新版本，交付给质量团队或者用户，以供评审 |
| 持续部署（Continuous deployment） | 持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境 |
三、场景
项目中不同干系人在持续集成和部署中会遇到的不同场景，如图所示
四、方案设计
1.结构设计
2.技术选型
使用GitLab Pipeline进行持续集成，主要考虑以下几个方面：
- 作为统一的持续集成入口，简化开发人员维护的难度
- 不需要配置WebHook，代码维护过程上下文也能够轻易感知
- 自身拥有一定的权限控制机制
- 流水线定义方便、灵活，学习成本较不算太高
- 提供的功能丰富，有利于流水线个性化定制，包括且不限于：分支模糊匹配、多语言的代码构建、测试报告、构建产物存储、性能测试报告等
- 官网文档丰富，版本迭代快，CICD功能上迎合了许多主流第三方工具或平台（如：k8s、sonar扫描、多语言构建镜像等）
- 提供分布式Runner，分散流水线不同阶段的资源压力
CICD工具对比
| 对比项 | Jenkins | CircleCI | TeamCity | Bamboo | GitLab |
|---|---|---|---|---|---|
| 开源 | 是 | 否 | 否 | 否 | 否 |
| 使用难度 | 中等 | 中等 | 中等 | 中等 | 中等 |
| 内置功能 | 少（需要插件） | 中等 | 中等 | 中等 | 中等 |
| 部署方式 | 本地 & 云 | 本地 & 云 | 本地 | 本地 | 本地 & 云 |
| 免费使用 | 是 | 是 | 是 | 是 | 是 |
| 操作系统 | Windows，Linux，macOS，Unix-like OS | Linux，macOS | Windows，Linux，macOS，Solaris，FreeBSD等 | Windows，Linux，macOS，Solaris | Linux：Ubuntu、CentOS、Debian等 |
