目前CI/CD技术成熟度较高，大部分公司都基于开源的产品（如Jenkins），构建了符合自己业务所需的CI/CD系统。做为前文的后续，这里我们将展开讨论一下设计CI/CD的要点以及在公司内部是如何解决的。

如上图所示，这是一个完整的CI/CD流程，其中的要点是，是否开放给研发操作完成系统上线。事实上很多公司为了防止研发误操作，CI/CD全部由运维负责，虽然避免了误操作的风险，但同时也带来了跨团队沟通的不变。从研发的角度来说也希望有更多的操作权限不过于依赖运维。本文我们讨论CI/CD开放给研发需要特殊考虑的事情，以及我们内部如何设计实现。

一、向研发开放CI

CI过程需要开发构建脚本无需多说，整个构建过程可视为一个Pipeline，目前有两种常见的方法：

无论使用哪种方法都面临一些问题：

在公司内部，我们采用了变通的方法来实现，我们开发了一个面向研发使用的CI/CD系统，被我们称为“研发云”，其后是被包装的Jenkins。创建项目时， 由程序创建一个Jenkins Job，Jenkins Job使用一种叫做“jenkins share library”的技术，关联预定义好存放在Git上的一个Pipeline脚本。所有Jenkins Job都引用相同的构建脚本，如果需要修改构建过程，直接修改Git上的构建脚本就可以全局生效。

二、向研发开放CD

对于研发来讲，当然希望无需运维协助就可以进行上线操作。如果开发CD能力，仍存在一些细节问题需要考虑： 

在公司内部，我们采用部署权限与Git项目权限相同的管理方法，解决上线授权的过程，简单来说，只要Git上有Owner、 Master权限就可以无需审批上线，而其他权限不可以上线，这样就避免了审批授权的问题。解决运行时环境管理问题，因为我们内部采用K8s部署应用，应用间本身就是环境隔离的，因此环境变量可以放开给研发随意设置。而系统配额则是由运维预先设置好，运行Deployment时，从数据库中读取配额生成Deployment在运行。

三、整合CI/CD

CI过程中构建出来的制品名称如何传递给CD环节也是一个问题。以ArgoCD为例，ArgoCD对一个项目的部署配置存储在Git上，每次部署时，都需要在Git上修改要运行应用所对应的Docker Image名称。CI到CD过程并不连贯，需要太多的人工介入。

四、解决方案

尽管开源的各种CI/CD工具功能非常丰富，但整体上讲，交互方面偏弱，完全开放给研发操作会带来很多问题，为此我们设计了“研发云”通过后台集成Jenkins，提供更为全面的交互来解决CI/CD过程中的一系列问题。

研发云首页

构建过程

项目工作台

系列文章