在上一期文章里,我们介绍了多环境下的应用配置管理问题,从这期开始,我们会分两期文章详细聊聊多环境建设的问题:就是我们到底需要哪些环境?这些环境都有什么作用?环境建设的思路和方式是怎样的?
今天我就结合自己的经验和理解与你聊一聊持续交付中的线下多环境建设。
环境分类
通常,我们主要按照环境所起到的作用,将环境分为两大类:
从建设角度来说,线下环境和线上环境,在网段上是要严格隔离的。这一点在做环境建设时就要确定网络规划,同时在网络设备或者虚拟网络的访问策略上要严格限定两个环境的互通,如果限制不严格,就极易引起线上故障,甚至是信息安全问题。
如果你维护过这样两套环境,我想你一定在这方面有过深刻的感受,甚至是痛苦的经历。
所以,从规划上,线上环境和线下环境是两套独立的区域,所有的应用、基础服务都是全套独立部署的。但是线下环境所需的资源往往是要少于线上环境,毕竟只有负责开发测试的少数人使用,不会有线上流量进来。如下图所示:
但是,在实际情况中,这两个环境远远满足不了我们日常开发、测试和运维方面的需求。从保障软件质量和系统稳定的角度出发,我们在实际操作中还需要在这两个大的环境区域中,建立细分的小环境,来满足不同阶段和不同角色的工作需求。
线下环境分类建设
线下环境最初建设的时候,主要是提供给测试使用,帮助其建立一个模拟环境,在软件发布上线前进行需求功能验证,保障业务流程顺畅,以确保应用在上线前达到最低质量要求。
所以,我们在线下环境区域内,建设的第一个环境就是集成测试环境。甚至在一开始,线下环境 = 集成测试环境,这个环境下的应用和各类基础服务必须跟线上保持一致,但是集群规模不用这么大(如我们上图所示)。
所以,集成测试环境极其重要,这个环境中的应用有严格的发布标准,并且要求环境稳定,不能随意发生变更,否则将会大大影响测试的效率。
不过,随着集成测试环境建设起来,业务需求迭代越来越快,应用和开发人员数量也越来越多,软件发布和变更也会更加频繁,这个时候就会出现开发和测试人员争抢集成测试环境的问题。
比较典型的场景就是,测试人员正在验证一个功能,突然发现应用停止运行了,原来开发为了验证和尽快发布新功能,更新了代码,这样就阻塞了测试的正常工作,但是不更新代码,开发的工作又会停滞下来。
后来这个矛盾越来越严重。这时,我们就需要考虑多建设一套给开发用的环境来解决这个问题。
于是,我们就开始建设线下的第二套环境:开发测试环境。这个环境主要是让开发同学能够尽快发布自己开发完的代码,并在一个具备完整业务应用和基础服务的环境下,验证自己的代码功能。
但是,是否需要跟集成测试环境一样,再建设一套独立完整的线下环境出来呢?答案是否定的。因为这时的应用变化范围相对独立,变化也较小,周边依赖需要同时变化的应用也不会太多,就像上面说的,只要能把它们放到一个完整的环境中进行验证即可。
所以,这个环境只要按照最小化原则建设即可,如果有依赖,可以直接访问到集成测试环境。在这里,我们以简单的模型展示开发测试环境跟集成测试环境的关系:
再往后,开发测试环境上,又会出现开发和测试的冲突和争抢,因为从场景上,业务开发团队可能要同时承担多个并行项目的研发,而且可能会有多个业务开发团队一起参与进来。
比如对于电商来说,到了年底,就集中会有“双 11”、“双 12”、“双旦节”以及“年货节”等等这样的大型营销项目,因为时间非常紧凑,所以就必须多项目并行。
这个时候,分解下来,对于我们的应用软件来说,有可能是存在多个开发分支的。到了项目联调和验证环节,就必然会存在同一个应用有多个版本需要同时发布和测试的情况,但是开发测试环境却只有一个,这就必然导致双方激烈的争抢。
所以这个时候,就必须建立解决冲突的方案,开始建设线下的第三套环境:项目环境。
项目环境可能有多套,一个项目对应一套环境,但是无论从资源成本还是维护成本方面考虑,项目环境仍然不会像集成测试环境那样形成一套完整的开发测试体系。
所以项目环境同开发测试环境一样,仍然是以最小化为原则来建设,也就是说,在这个环境里面,只部署同一项目中涉及变更的应用,而对于基础服务和不涉及项目需求变更的应用不做重复建设。如果对项目环境中不存在的应用有依赖,那么访问集成测试环境中对应的应用就可以了。