使用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无法满足,再进行切换即可。

你可能感兴趣的:(ci,jenkins)