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





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

一、向研发开放CI

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

1. 以Jenkins为代表的工具，在Jenkins里编写Pipeline脚本。

2. 以Gitlab CI为代表的新型工具，在项目代码里编写Pipeline脚本。

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

1. 研发是否具有能力开发Pipeline脚本。

2. 如何保证公司的技术规范贯彻执行，比如为了加强代码质量在构建过程中进行代码质量检查、漏洞扫描、自动化测试等等。如果由研发构建Pipeline脚本，很难保证这些规范被严格遵守。



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

二、向研发开放CD

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

1. 如何做上线审批，Jenkins执行过程中，可以引入确认动作，当确认后才能执行后续动作，但具体的一个项目需要谁来进行授权后才可以进行部署，这种细粒度的控制在Jenkins中比较难以实现，而且交互体验不友好。



1. 如何做运行时环境管理，通常程序运行时需要设置一些环境变量、资源配额。如果完全开放给研发，则可能随意进行设置，引发全局性系统故障，如何防止出现这种情况也是要考虑的。

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



三、整合CI/CD

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



四、解决方案

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



研发云首页



构建过程



项目工作台



系列文章

一、创业公司技术体系建设

二、创业公司技术体系建设-CI/CD

三、创业公司技术体系建设-APM