[发明专利]一种环境变量替换使用的方法、系统、设备和存储介质

说明书

本发明提供了一种环境变量替换使用的方法、系统、设备和存储介质，方法包括：判断用户根目录下是否存在环境变量文件；响应于用户根目录下存在环境变量文件，将所述环境变量文件复制到系统根目录下；合并初始环境变量和所述环境变量文件生成最终环境变量对象，并判断React应用当前是本地启动还是生产环境打包；以及响应于React应用当前是本地启动，将所述最终环境变量对象放入所述系统根目录下。本发明通过将初始环境变量和注入环境变量合并，并将形成的最终环境变量对象放入所述系统根目录下，使得在多个环境的部署过程中，只需要构建一次最终环境变量对象，简化了应用部署安装流程。

技术领域

本领域涉及应用开发领域，更具体地，特别是指一种环境变量替换使用的方法、系统、设备和存储介质。

背景技术

ICM平台(浪潮自主研发设计的云海管理平台)UI(User Interface，用户界面)是使用react进行构建开发，通过Kubernetes部署。服务新功能开发完成过程中会被依次部署到研发环境开发测试，测试环境验收和生产环境使用。

多个不同使用场景决定了变量的使用不能采取值写死的方式，因此希望找到一种动态替换的方式满足需求，希望能够将React应用程序使用Docker(容器)运行，只构建一次，能够在任何地方运行，并且希望在运行时提供重新配置容器的时机，允许在docker-compose(容器组成)文件内进行变量配置。

React应用在开发中，有两种不同的环境变量。一种是在编译时已经确定的环境变量，通过类似config.js的配置文件进行配置；而另一种是在部署时(运行时)才确定的环境变量，比较常见的是根据环境进行区分的一些变量，比如API(Application ProgrammingInterface，应用程序接口)请求地址前缀，根据部署的环境不同而不同。当前端镜像生成后，需要通过外部去注入这个变量。

多数方案将两种环境变量混合在一起，导致很难区分编译时已经确定的环境变量和部署时确定的环境变量，也就无法确定可以注入修改的环境变量。以下面代码为例：

let env＝process.env.NODE_ENV

let baseUrl＝”

if(env＝＝＝'development'){

baseUrl＝urlDev

}else if(env＝＝＝'production'){

baseUrl＝urlProd

}

可以非常明显的看出，上述代码中的环境变量需要通过不同的环境来确定编译时已经确定的环境变量和部署时确定的环境变量。

发明内容

有鉴于此，本发明实施例的目的在于提出一种环境变量替换使用的方法、系统、计算机设备及计算机可读存储介质，本发明通过将初始环境变量和注入环境变量合并生成最终环境变量对象，并将最终环境变量对象放入系统根目录下，使得在多个环境的部署过程中，只需要构建一次最终环境变量对象，简化了应用部署安装流程。

基于上述目的，本发明实施例的一方面提供了一种环境变量替换使用的方法，包括如下步骤：判断用户根目录下是否存在环境变量文件；响应于用户根目录下存在环境变量文件，将所述环境变量文件复制到系统根目录下；合并初始环境变量和所述环境变量文件生成最终环境变量对象，并判断React应用当前是本地启动还是生产环境打包；以及响应于React应用当前是本地启动，将所述最终环境变量对象放入所述系统根目录下。

在一些实施方式中，方法还包括：响应于React应用当前是生产环境打包，将所述最终环境变量对象放入所述系统根目录下，并复制所述环境变量文件、初始环境变量和最终环境变量对象到dist目录下。