首先来考虑一个问题,你是否会把持续集成的代码、编译、打包的过程部署于生产环境?为什么?
如果真正懂IT治理过程的话,10个人有9个半是不会这么做的,这也是我们接触容器云平台这么久来让我们觉得不可思议的地方。你说容器技术调研、PoC验证可以这么做,生产还这么做?上生产还能拿小孩子过家家的玩艺儿去部署?是不是不可思议?目前大部分容器云产品至多算是个玩具,至多是PoC概念验证的工具,完全不具备生产部署的要求。这也是我们为什么一再强调要把CI持续集成从容器云平台资源和应用管理分离出来,成为独立的一个模块或产品,实现标准化镜像输出能力的原因。
想想阿里为什么有个云效平台,想想IBM为什么推出的是基于容器技术的微服务管理平台,特别传统行业,谁会傻到在生产环境上去开发、编译、 测试?不过还真别说,目前看到的容器云产品基本上都是傻傻的分不清。所以这也是我们重点提出来讨论的原因。
持续集成流程终点应该是镜像仓库,持续集成只服务于开发测试阶段,是不需要在生产环境中体现的。 持续集成需要做的是实现自动化的源码检查、编译、单元测试、镜像打包、镜像上传、镜像安全扫描等能力。最重要的是不要让用户自己再写docker file等,需要通过提示客户输入或选择实现自动化的docker file生成。减少终端客户的学习成本。
既然这样,那持续集成或 pipeline工具就应该单独拿出来作为独立的产品或组件,提供持续集成服务。就像jenkins那样,配置一下jdk、maven、Git or SVN等工具,实现自动化的docker file生成(选择基础镜像,添加需要的文件等到基础镜像,设置端口影射等,自动生成docker file),连接到镜像仓库,上传镜像,完成这些步骤后在镜像仓库就可以看到新的镜像。这样对用户来说很友好。至于说是用jenkins或者自定义的pipeline,都没什么关系。作为用户我关注的是结果——镜像,中间过程可以是透明的(除了需要选择基础镜像,选择上传文件等UI交互操作)。