我想问个小白问题:
1.与互联网企业不同,课程中讲述的开发、测试、预投产、生产环境的系统部署版本是如何保持一致的?
2.在统一版本化管理中的可重复、可追溯方面有什么特色做法?
问题一:环境一致性
容器镜像把应用及其运行所依赖的环境都打包在一起了,因此运行的时候对所在节点的环境依赖基本没有要求。例如,应用A需要在java1.8环境运行,开发环境是java1.8,测试环境是java1.9,生产环境是java2.0,应用A的镜像是可以在开发、测试、生产中运行的。
问题二: 统一版本化管理
容器云可以通过流水线自动化完成从代码到容器镜像的构建过程。结合DevOps平台,就可以实现对开发的需求A构建成镜像A1,镜像A1运行在容器app-A1上。反之,也能推算出来。
1.首先,这四个环境的基础版本是一致的,也就是说最早都是基于master拉取的四个分支。 在传统金融行业,开发完毕后,会将相关代码提交到测试分支。因为金融行业严格要求需求可追溯性,所以代码和需求编号是强关联的。在从开发分支提交到测试分支的时候,开发人员选择他需要提交的需求,那么相关的代码就从开发分支合并到测试分支。从测试到预投产(准生产)分支,也是一样的过程。其实严格来讲,这几个分支的代码是有差距的,因为不是所有的需求都会在这一批投产,也有可能有些需求由于各种原因最后放弃上线。但是我们要保证的是,测试环境,预投产(准生产)环境的代码是经过各种严格的测试(单元测试,扫描,自动化测试,手工测试,压力测试),因此在预投产环境的代码是完全可用且符合预期的。实际上开发,测试,预投产这几个分支代码是有差异的,但是预投产分支的代码最终上线后,会把这个分支的代码合并到生产分支,所以预投产和生产环境是无差异的。 在多版本迭代后,开发人员一般会基于生产分支拉取新的开发分支。