容器云第一期课程里面讲的统一版本化管理是怎么实现的？

问题一：环境一致性
       容器镜像把应用及其运行所依赖的环境都打包在一起了，因此运行的时候对所在节点的环境依赖基本没有要求。例如，应用A需要在java1.8环境运行，开发环境是java1.8，测试环境是java1.9，生产环境是java2.0，应用A的镜像是可以在开发、测试、生产中运行的。

问题二： 统一版本化管理
      容器云可以通过流水线自动化完成从代码到容器镜像的构建过程。结合DevOps平台，就可以实现对开发的需求A构建成镜像A1，镜像A1运行在容器app-A1上。反之，也能推算出来。

1.首先，这四个环境的基础版本是一致的，也就是说最早都是基于master拉取的四个分支。 在传统金融行业，开发完毕后，会将相关代码提交到测试分支。因为金融行业严格要求需求可追溯性，所以代码和需求编号是强关联的。在从开发分支提交到测试分支的时候，开发人员选择他需要提交的需求，那么相关的代码就从开发分支合并到测试分支。从测试到预投产（准生产）分支，也是一样的过程。其实严格来讲，这几个分支的代码是有差距的，因为不是所有的需求都会在这一批投产，也有可能有些需求由于各种原因最后放弃上线。但是我们要保证的是，测试环境，预投产（准生产）环境的代码是经过各种严格的测试（单元测试，扫描，自动化测试，手工测试，压力测试），因此在预投产环境的代码是完全可用且符合预期的。实际上开发，测试，预投产这几个分支代码是有差异的，但是预投产分支的代码最终上线后，会把这个分支的代码合并到生产分支，所以预投产和生产环境是无差异的。 在多版本迭代后，开发人员一般会基于生产分支拉取新的开发分支。

2. 因为传统行业对于需求追溯有严格的要求，所以我们需求和代码是关联的。开发人员提交代码必须绑定需求编号，以便于后续追踪。在版本（制品）管理中，我们使用的是制品库，制品库分为开发测试制品库和准生产制品库，任何一个上线的包都可以追溯到制品库，进而追溯到需求列表。