持续集成和容器云平台的关系？

首先来考虑一个问题，你是否会把持续集成的代码、编译、打包的过程部署于生产环境？为什么？
如果真正懂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交互操作）。