Why #

传统的软件交付，强依赖人力，需要运维/开发人员手动执行脚本，手动传输文件( ftp/oss 等)

这么做比较低效且容易出错，由此诞生了很多自动化的系统，用于简化软件交付的成本，提高交付安全性和稳定性

市面上这些成熟的系统有 Jenkins，Gitlab CI， CirCle CI 等，那么在企业内部，为什么我们还需要额外的 CI 系统?

Jenkins 局限性 #

1. 插件系统复杂，不利于维护
2. 人员管理，权限管理，CI 模板管理
3. 不是很好用的 UI 和交互
4. …

Gitlab CI 局限性 #

1. 开源软件，但额外的功能需要付费订阅
2. 跟 Gitlab 强绑定，存在版本差异 (cache, yml 配置等)
3. 人员管理，权限管理， CI 模板管理，发布审批等功能不完善
4. 配置复杂，学习成本高
5. 每个仓库都必须有 .gitlab-ci.yml 文件，容易被开发误改，带来安全风险
6. ui 及交互复杂 (all in one)
7. 私有部署的 gitlab 的维护强依赖基础运维团队，跨大版本升级有风险

发布审批功能如下图所示，需要在 14.7 的高级版以上支持，且为 beta 阶段

基于文件的 cache 策略及配置，要在 12.5 版本后支持

模板继承 要在 11.4 版本后支持

所以，如果需要用到 gitlab 的全部高级功能，那么得去升级到高级版 (premium) 才行，价格如下图所示, 详情可参考 gitlab 官网，

企业级 CI 的需求 #

对企业而言，环境的稳定性，发布安全性，是很重要的

所以 CI 的执行，需要很强的人员管理，权限管理等

人员管理 #

对某个 Git Repo 而言，只能指定的人员去触发 CI

CI 配置管理 #

只允许指定人员修改 CI 的配置

时间窗口管理 #

只允许指定的时间段去执行 CI，保障环境的稳定性

审批管理 #

指定环境的 CI 执行需要额外的人员审批后，方可执行

Pulse CI #

Pulse CI 旨在满足企业级的 CI 需求，同时从开源方案中吸取优秀经验，为开发者提供良好的使用体验，降低学习成本

设计理念 #

1. 基于 Gitlab 的人员管理，组管理提供权限管理
2. 基于 .gitlab-ci.yml 的子集实现 CI 配置模板
3. 提供良好的用户体验和使用文档，降低学习和维护成本
4. 提供通用解，能解决大多数企业的内部使用场景