已有开源工具中, 我平时使用的是azure的pipeline(私有项目), 以及travis-ci(公有项目), 个人比较喜欢azure的, 可以自建agent, CI结束之后顺便将部署工作也完成.

自建CI工具的一些调研

部门中使用的git仓库并不是gitlab这样的开源git仓库. 也没有支持第三方应用, 目前只有webhook可以使用, CI工具的选择上少了许多, 即使使用开源的CI工具, 也要自己定制一番. 另外, 由于我已经维护了一个PaaS平台, CI工具也是为它服务, 所以也会考虑这个平台的相关问题.

本文只探讨一些可以自建服务的CI系统, 并就使用功能情况, 用户上手难易程度, 定制难度, 部署难度做一些简单的探讨.

CI工具的大部分资料来源于:

https://ligurio.github.io/awesome-ci/

https://alternativeto.net/software/travis-ci/?platform=self-hosted

Jenkins

Jenkins之前我就自己写过一些配置文件. 个人看法: 独立的大型项目使用jenkins是比较合适的, Jenkinsfile的功能很强大, 可以做到包括启动docker镜像, 生成virtualenv环境, 以及自定义通知的功能.

Jenkins有一点不好就是你需要写的东西太多了, 部署在PaaS平台中的应用不大, 但是比较多. 每个应用开发者都写jenkinsfile既不利于维护, 也增加了成本. PaaS平台中的应用, 所需要的CI都是简单的跑几句单元测试语句, 最多可能需要启动一个mysql或者redis, 使用原生的Jenkinsfile感觉大材小用.

Agola

开发栈: Golang + Vue 数据库: etcd

https://agola.io/

总体来说, 我并不喜欢agola的文档, 按照它的方案搭建giteaagola也许可以成功, 但会有一种云里雾里的感觉, 强烈建议大家开始时使用Github的API进行, 而且, 你需要一个公网域名和服务器. 程序有一些BUG, 用户可能会因为一些莫名的错误而产生挫败感, 建议做好hack的心里准备.

我试用了比较多, agola使用oauth2登录的形式进行验证与授权. 它可以作为Github, Gitlab的一个应用进行使用,

agola运行时的流程:

  1. 申请Github应用, 获得clientidsecret
  2. 使用agola remotesource create的方式, 增加其作为Github应用
  3. 用户登录, 创建项目(程序后台去github中设置hook)
  4. 当用户修改了代码, 触发hook时, 进行构建

优缺点分析

优点

  1. 开源自己可以部署
  2. 完成度比较高, 可以在框架中做一些改动

缺点:

  1. 用户界面用起来并不是很舒服, 比如有几个按钮不太方便去点击, 点击起来和想象的功能不太一致, 任务页面的标签太大, 显得内容空洞
  2. 虽然使用yaml文件, 但是有点罗嗦, 看文档也仍然没找到比如redis,mysql这种服务的预先加载功能
  3. 程序中仍然有一些BUG, 我在页面载入时/不知为什么会转义成%2F
  4. 构建时的变量设置虽然有这个页面, 但我依旧没有找到从哪里设置

如果PaaS项目中想要接入这个CI工具, 比较可行的方案是:

对PaaS平台:

  1. 实现一套oauth的认证登录, 以及粗略的授权系统. 使得agola可以利用PaaS平台进行登录, 并有能力获取其中的一些项目.
  2. webhook需要平台进行中转
  3. 当前情况, agola的yaml代码比较复杂, 可能需要简单的实现一个yaml转换器

对agola平台:

参照github的oauth增加部分代码, 另外需要修复一些BUG(类似上面的路径问题).

Abstruse CI

开发栈: Golang + Angula

https://github.com/bleenco/abstruse

最后一个release版本是18年12月的, 尝试docker启动之后, 也和agola一样, 可以通过oauth的方式进行接入, 也可以使用自己的用户系统, 但是接入oauth登录之后, 只能看到在github的项目, 但我始终不知道该如何编写CI文件使其运行. 放弃了.

Concourse-CI

开发栈: Golang

有个同学之前已经搭建并写了一篇博客, 我是是参考他的:

https://www.boris1993.com/tools/concourse/concourse-quick-start.html

这一种较为独立的CI工具, 起初我以为它功能孱弱, 但是使用了之后才发现, 它其实更专注于CI/CD的功能.

优缺点分析

优点

  1. 完成度较高
  2. 相比于复杂的Jenkins, 它的配置已经十分简单
  3. pipeline的部分, 文档较为完善, 也有示例项目, 比agola好很多

缺点

  1. 用户配置界面功能几乎没有, 所有操作需要靠命令行工具fly实现
  2. 用户系统需要单独建立, 也无法去支持oauth2这种, 如果一开始要打算支持Gitlab或Github的项目, 那就不要考虑了

比较可行的接入方案

对于Concourse-CI平台:

  1. 搭建好该平台后, 需要借用OpenID作为校验工具登录
  2. 需要维护用户组信息

对于PaaS平台:

  1. 用户创建项目后, 需要渲染一个Concourse-CI的pipeline, 并将pipeline绑定到对应的组中
  2. 定时同步用户组信息至CI系统中

相比agola, PaaS平台的中的修改可能更少一点, 因为不需要完整的实现一套oauth2系统了.

总结

有两种风格的CI系统, 一种类似TravisCI, 可以自动导入仓库中项目, 并解析项目中的ci文件, 另一种是类似Jenkins, 需要手动创建项目, 指定CI流程.

Agola是一个类似于本地TravisCI的系统, 可以兼容多种在线仓库, 基本上只要提供了oauth的支持, 都可以接入到系统中. 现有的系统想要接入, 最好要提供oauth2的基础系统功能, 未来的扩展性也很强.

Concourse-CI更像是一个精简版的Jeknins, 当然它更加轻量, 使用yaml的描述型语句可能没有groovy这样的语句强大, 但是作为CI已经足够用了, 参考TravisCI的功能, 简单的做一些扩展应该也足够用了. 开发与接入周期短, 因为与现有平台结合相对紧密 未来的扩展性可能没那么强.