传统Devops VS Gitlab全家桶？

有两点要关注，第一点，工具链的选型，第二点，DevOps最终的价值
关于第一点，工具链的选型，首先要看面向对象，基于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组织自身，最终到企业都获得相应的收益。