银行对生产测试开发环境要求物理隔离，容器云平台提倡devops、CICD，如何平衡这之间的矛盾？

正常来看生产和测试环境虽然独立建设和运维，但不会完全隔离。一般网络上会通过防火墙进行隔离，生产和测试路由层面打通。不管是CICD的需要还是其它测试到生产的版本传递，或生产到测试的数据传送，都需要从网络上将测试和生产按需打通，当然需要从时间段，明细需求上进行有效控制，这是网络层面。其它数据传递则一般需要有专门的中转平台或产品来实现，简单一点的是SVN,复杂和成熟一点的需要专门的产品做自动化集成，以及结合相应的安全管控(如权限控制，时间控制等)实现，已满足安全和流程要求。

有的银行的做法是在DevOps的CICD通到开发和测试环境，提升应用的开发测试效率。当然要求DevOps平台的部署机要和开发和测试环境打通。
而对于生产环境，通过把镜像和部署模板等工件移交部署组，由部署组在自己的部署平台上做自动化的部署。(或者手工部署)

看到核心的诉求是：要求物理隔离的情况下如何做到CI/CD自动化.

我简单理解成，在有操作间参与的环境如何实施devops，两者理念看似冲突，但也可以看成前者模式给后者提出了安全合规的需求, 如何更安全可控地进行变更，更多相关介绍可以搜索DevSecOps领域：
1. CI/CD 有时也叫流水线，流水线可以有分支、审核等待等环节

2. 每次CI/CD的自动化操作都具备分支能力，能覆盖到日常手动变更的细节，如回退操作等.
   3. 变更间的操作，也可以流水自动化，投产的CI结束点是把投产包加密拷贝到U盘，审核通过可以得到秘钥，U盘拿到变更间，插入后自动解密，并上传到部署服务中。
   4. 这个角度来看容器云是让自动化运维相对更好做了一些。

目前的解决方法，基本都是开发测试环境和生产环境的部署过程是分割开的。DevOps只管理开发测试环境；在UAT后将制品同步到生产环境进行部署，这个过程，不管有没有工具支持，都需要开发运维人员在场，手工启动。
问题的关键其实不是物理隔离，而是大部分银行目前还是不能接受生产环境系统每天几个版本的快速发布。

开发测试环境和生产环境物理隔离:
1、有些企业是通过镜像(或者+程序包)中转方式，如通过文件服务器作为中转，把镜像和程序包通过文件服务器从开发测试环境到生产环境；
2、还有一些企业是通过开墙方式，一般是把镜像从开发测试仓库传到生产环境镜像仓库；
3、还有一些人是通过其他手段，如拷贝镜像等方式，把镜像或者程序包从开发测试环境到生产环境；

这里要注意一个问题，部署组由于更关注部署的可靠性和准确性，对CICD/devops的技能掌握是非常弱的。开发测试之后要交付的版本，特别是在配置上，一定要最大程度地模拟生产环境，对于部署脚本，配置信息，要提前为生产环境做好准备。
如果通过镜像流转的方式来交付，特别要注意对基础镜像和部署配置的修正，不能把这问题留给生产环境的部署和运维人员。

大家回答了直接用镜像库流转，我谈谈我们采用的另一种模式，容器启动时采用模式：标准基础镜像+程序包+配置文件 。
容器平台在面对测试开发时，最常见的就是换包和换配置。应用先做好配置分离改造，容器平台做好配置管理模块。发布时利用每个环境标准统一的基础镜像去映射程序包的文件+各个环节的配置启动即可。
这种模式的好处是可以复用原有的开发测试生产发布交付物流水线，改造成本低。缺点是待启动的每台宿主机需要传包。适合每个项目独立的小池集群场景，不适合混用大池集群场景。