当多分支并行开发或者能够发版到生产环境的分支较多时，很容易在手动部署的阶段点错，或者看串行，当然这种概率很小。

但是我们可以看到另外一个问题，每次提交或者合并，都会触发构建，当我们使用Git Flow分支流时，可能同时有很多分支都在并行开发、并行测试、并行构建，如果Git Runner是基于虚机创建的，很有可能会出现构建排队的情况，当然这个排队的问题，也是能解决的。

其次，如果一个项目稍微大一些，维护起来也不是很方便。比如这个准备要迁移的项目，一个前端和二十多个业务应用，再加上Zuul、ConfigServer、Eureka将近三十个服务，每个服务对应一个Git仓库，然后每个服务同时在开发的分支又有很多，如果想要升级GitLab CI脚本或者微服务的机器想要添加节点，这将是一个枯燥乏味的工作。

最后，还有一个安全的问题，GitLab的CI脚本一般都是内置在代码仓库里面的，这就意味着任何有Push或者Merge权限的人都可以随意的修改CI脚本，这会导致意想不到的结果，同时也会威胁到服务器和业务安全，针对发版而言，可能任何的开发者都可以点击发版按钮，这些可能一直都是一个安全隐患。

但是这些并不意味着Git Runner是一个不被推荐的工具，新版的GitLab内置的Auto DevOps和集成Kubernetes依旧很香。但是可能对于我们而言，使用Git Runner进行发版的项目并不多，所以我们想要统一发版工具、统一管理CI脚本，所以可能其它的CI工具更为合适。