争议 | 传统 DevOps VS GitLab 全家桶,如何抉择?

发布于 2021-01-28 08:52

来自twt社区同行交流，欢迎更多同行参与交流

传统DevOps VS GitLab全家桶？

大量企业早期的Devops实现主要是集成Jenkins+Sonar+Gitlab+Artifactory等等工具链方案，而各个应用内部的权限管理或者相互对应关系，又催生了定制在工具链之上的Portal。但是新形式下的类似Gitlab全家桶方案与之对比，不仅用户管理简便，内部数据更安全。一方面是大量知识积累和存量用户，一方面是更安全和快捷的实现，如何抉择？但应该坚持要做好CI/CD。

问题来自社区会员@Joey_1991 保险云计算高级工程师，下文来自twt社区众多同行实践经验分享，欢迎大家参与交流，各抒己见。

* “争议”栏目内容来自同行分享的一手体验和观察，仅代表个人观点

@顾黄亮苏宁消费金融有限公司技术总监：

关于第一点，工具链的选型，首先要看面向对象，基于jenkins的devops工具链，面向了DevOps价值交付全流程中的能力子域，基于gitlab的DevOps工具链，更直接的面向研发人员，可以这么说，在强调敏捷的DevOps交付项目中，适合使用gitlab，开发、测试、运维采取无边界的方式进行交付工作。

再回到工具链本身， gitlab 通过gitlab-runner进行CI/CD，配置很简单，很容易与gitlab集成。当新建一个项目的时候，不需要配置webhook回调地址，也不需要同时在jenkins新建这个项目的编译配置，只需在工程中配置gitlab-ci.yml文件，就可以让这个工程可以进行编译。gitlab-runner没有web页面，但编译的过程直接就在gitlab中可以看到，不需要像jenkins进入web控制台查看编译过程。gitlab-runner仅仅是提供了一个编译的环境而已，全部的编译都通过shell脚本命令进行。当然，jenkins也可以是全部的编译都通过shell脚本命令进行。

jenkins的好处就是编译服务和代码仓库分离，而且编译配置文件不需要在工程中配置，如果团队有开发、测试、配置管理员、运维、实施等完整的人员配置，那就采用jenkins，这样职责分明。不仅仅如此，jenkins依靠它丰富的插件，可以配置很多gitlab-ci不存在的功能，比如说看编译状况统计等。如果团队是互联网类型，讲究的是敏捷开发，那么开发=devOps，肯定是采用最便捷的开发方式，推荐gitlab-ci。

第二点，devOps最终价值，devOps有锚定价值的作用，提升组织级的能效和质量，随着devOps原生理念的延展，devOps的价值变得更为丰富，无论对IT组织各能力子域，还是IT组织自身，最终到企业都获得相应的收益。

@wangchang365 兴业数字金融服务（上海）股份有限公司研发工程师：

这个个人认为需要综合来看。

Jenkins+Sonar+Gitlab+Artifactory+ Portal 大多是企业一步一步根据自身实际构建起来的，一般在建设的时候 GitLab还并没有形成全家桶的支持。

现在来看，已有工具链的企业综合考虑熟练度和用户情况，不建议选择GitLab全家桶。

新打造CICD体系的话，可以把 GitLab全家桶纳入支持。

@Okabe：

Gitlab全家桶在Devops包含的功能：

现在gitlab确实已经已经涵盖了绝大部分devops的需求了。从前期的测试，到部署后的监控都全部有覆盖到。

如果使用gitlab全家桶对于一线研发人员来说会非常的爽。因为gitlab不单单是一个能提供代码管理能力的devops工具。项目管理、代码review、甚至维基文档都可以在上面完成。研发人员和项目经理可以在研发和管理应用时直接看到一个commit是否通过cicd的各个流程，对性能、功能覆盖率是否造成什么影响。

将代码的编写-审查-测试-编译-打包-发布的流程都使用同一个平台进行统一管理，这种由统一生态提供的效率提升我认为是会比大量产品堆叠在一起高不少的。

不过说白了devops只是研发中的一环，如果公司在这方面已有大量的积累，且这个devops确实能满足需求，那么也没有什么特别的切换的必要。毕竟devops本身不生产价值。如果说维护现有工具链成本大，或者是其中部分依赖项出现了问题（停止维护），那么gitlab确实是一个不错的选择。gitlab本身也是开源程序，特殊需求也可以通过定制解决。

@ht025：

1 、 Jenkins CI / CD 和 GitLab CI / CD 功能对比

2 、 Jenkins 与 GitLab CI / CD 之间的区别

（ 1 ）借助 GitLab CI / CD ，你可以完全控制分支和其他几个方面来控制 Git 存储库，以确保代码免受突发威胁。但是，在 Jenkins 情况下，你只能几个控制存储库。它不允许完全控制分支和其他方面。

（ 2 ） Jenkins 是 “ 内部托管 ” 的，并且是 “ 免费开放源代码 ” ，这就是编码人员偏爱它的原因。另一方面， GitLab CI / CD 是 “ 自托管 ” 和 “ 免费 ” 的，这就是开发人员更喜欢它的原因。

（ 3 ）在 GitLab CI / CD 中，每个项目都有一个跟踪器，该跟踪器将跟踪问题并执行代码审查以提高效率。在使用 Jenkins 工具时；它更改了支持、安装和配置过程。

3 、 Jenkins vs GitLab CI / CD – 功能差异

（ 1 ） Jenkins 的优点

大型插件库

自托管，即完全控制工作区

轻松调试运行，从而完成工作区控制

易于设置节点

易于部署代码

很好的凭证管理

功能灵活多变

支持不同的语言

非常直观

（ 2 ） Jenkins 的缺点

复杂的插件集成

较小项目的开销，因为您必须自己设置。

缺乏对管道的整体跟踪的分析。

（ 3 ） GitLab CI / CD 的优点

更好的 Docker 集成

扩展跑步者很简单

分阶段并行执行作业

直接环形管道机会

并发运行程序具有很好的可扩展性

合并请求整合

容易添加工作

易于处理冲突问题

良好的安全和隐私策略

（ 4 ） GitLab CI / CD 的缺点

需要为每个作业定义工件并上载 / 下载。

在实际合并发生之前不太可能测试分支的合并状态。

目前尚不支持阶段中的阶段。

4 、 Jenkins vs GitLab CI / CD 选择

Jenkins 和 GitLab CI / CD 都有各自的优缺点在两种 CI / CD 工具之间的最终选择完全取决于项目要求和规范。Jenkins 用于持续集成，而 Gitlab CI / CD 用于代码协作和版本控制。

@Steven99 软件架构设计师：

DevOps并不只是一套工具，更多是思想和方法，用DevOps的思想、方法、工具、流程等来协调开发团队和运维团队的关系、提升研发运营效率、促进高效文化的建设和持续改进。所以选择jenkins或者Gitlab来实现DevOps工具链并不冲突。工具选型通常要基于自身技术能力和技术积累，适合别人的不见得适合自己。

很多人可能对DevOps存在误解，仅认为DevOps就是CICD。Google SRE是对DevOps思想的一种比较好的实践，你看Google SRE并没有强调选择什么样的工具，而是从运维的视角通过研发来保证系统的稳定和可持续性。从而达到开发和运维的统一。

Gitlab全家桶提供了很多工具选择，类似于Spring提供了众多的框架和组件，但这些工具并不是开箱即用的，往往需要额外的工作，特别是开源的组件和工具，在持续不断的变化中。所以至于选择什么样的工具和组件，要基于实际的情况来决定。熟悉的组件用起来会更省时省力，所谓熟能生巧，不熟悉不了解的可能需要花很多时间学习，有学习成本。不同的情况不同的人效果是不一样的。我一直认为，技术没有绝对的好与坏，要根据自己的实际情况来选择。

@cpc1989 某保险公司存储工程师：

说一些个人浅见，如何抉择，很多时候不仅仅是技术问题，传统Devops工具链有一定历史包袱，可能受制于开发，测试，运维这样的组织架构和人员职责划分的限制，不同用户又有各自的工具使用偏好，这也会是工具链迁移中比较大的阻力。

@xiaoping378 光大科技有限公司系统架构师：

我们曾经针对gitlab能力做了一个项目生命周期管理图，基本全部能覆盖。