0penShift是如何支撑持续交付的？

感谢郭经理的专业答复，郭经理将完整的持续交付流程描述的非常清楚。在这里我只补充一点

在另一个问题的答复中我也提到 OpenShift 与大部分主流的开发体系是可以无缝对接的，比如 jira 、Iris、github 、gitlab。 用户可以仍然使用其原有习惯发起统一持续发布任务，能够有效的实现代码的持续集成持续发布的目的。 但在实现持续发布的过程中通常我个人愿意建议企业级用户将实现持续交付的镜像库分为三层。用户只与第一层和第二层镜像库发生自动化关联的持续发布，第三层处于生产区，其持续发布是独立的倾向 Ops 的，而不是 Dev 的。

第一层，是企业级基础镜像库，它将用于存储企业内部所有用于基础构建的的基础镜像，包括通过一些前期沉淀形成的技术型基础镜像，用于帮助企业内部实现基础镜像统一化、安全化、可控化。特别是一些基础的安全防范、安全扫描、漏洞扫补都需要在这一层完善，保障整体企业持续构建的安全可靠。在一些大型企业中，这个基础镜像库可以是去中心化多点同步的，包括在边缘计算场景中，这个基础镜像中心也可以是全国统一同步的。

第二层，是OpenShift内部镜像库，在OpenShift 内是通过 Image Streams组件提供的，它的任务是承载/管理用户在持续构建中不断创建各种版本的业务镜像。这部分能力 OpenShift 已经完全为用户设计好了，在 OpenShift 中它是租户隔离的。可以与基础镜像及产品镜像库自动安全互通的，但是被安全隔离的中间镜像库。

第三层，是真正的产品镜像库，它的任务是承担所有产品化版本的镜像。除了保障镜像的安全、可靠外。它的变更是需要审批的，他的入库是自动化的，通过版本控制统一调度的。因为它将会承担最终面向用户的产品版本镜像。企业将基于这个镜像库来完成最终产品化镜像的发布与回退。因此它的镜像必须具备完整的轨迹管理与审计管理，必须要保留完整的版本序列。保证业务发布时，不同组件间的版本同步性，同步上线或同步回退。

虽然第一层和第三层有时候在物理上可以合一，但逻辑上还是要分开的，因为其中的管理策略会有差异。