使用gitlab runner 进行CI（一）：gitlab runner与jenkins的选择

前言

现在挺多公司使用gitlab管理代码，我司也是。在开发人员发起代码合入请求（merge request)时，如果能先进行一些前置检查（包括单测、静态检查、编译检查等），那就既减轻了code review人员的负担，也能更好的保证代码的正确性和稳定性。以前jenkins是这方面的不二之选，不过现在gitlab自己也提供了一个叫gitlab runner的工具来做这件事，那么如何进行选择呢，其实也没有固定答案，完全根据需要和实际场景选用，下面我从自己的使用体验来谈谈这两个的优缺点，使用时间不长，可能并不会全面，特别是jenkins，只是简单的安装配置，没有长时间使用。

jenkins:

优点：
发展时间较长，各种功能的插件多
各种操作和源代码分离
独立的页面，可以管理多个项目
缺点：
配置相对复杂
需要进入web控制台查看编译过程

gitlab runner:

优点：
和gitlab完全融合，在merge request页面就可以看到结果
配置简单，容易上手
缺点：
配置文件和源代码在一起，相对不隔离
功能比jenkins少

如何选择

个人感觉gitlab runner更适合全是开发的团队（比如一个部门）使用，而jenkins适合有专门测试人员的公司或部门使用。gitlab runner 配置简单，所见即所得，不需要单独的web控制台，直接在gitlab即可查看各种检查是否成功，而我们团队没有专门的测试，因此选择gitlab runner更合适。如果未来有的需求gitlab runner无法满足，再进行切换即可。