关于生产环境以及测试环境的一些想法

起因

区分production环境和staging环境是一个很好的习惯,一方面可以避免测试数据不会和生产环境混在一起,这样很痛苦,而且很难区分什么是有用的,什么是没有用的。另一方面,就是这是一个成熟的工程师应该遵循的practice。
与此同时,就带来了一个问题,你是区分配置文件,还是区分应用?

区分配置文件

顾名思义,通过不同的环境变量NODE_ENV或者RAILS_ENV这样的环境变量在程序中去动态的加载一些配置文件,可以访问不同地点数据库,不同的第三方服务等等。

区分应用

这个就比较简单,把staging和production当做两个不同的应用去部署,可以放在一个服务器,也可以放在不同的服务器中,一套code,不同的也是配置文件的不同,或者启动命令不同,但是大致上就是这个思路。

以上两种

其实并没有一个特别好的方案,当你应用不大的时候,又需要区分production以及staging环境的时候,比较推荐第一种方案,理由有一些,比如不需要部署到两个地方,对于程序资源的利用率比较高,修改代码可以很方便快速的看到效果,只需要切换一下配置就可以转入生产环境了。
第二种,其实比较工业化,比如有些feature你可能还在测试当中,并没有说要立即发布到production中,所以这个时候分开部署是一种比较好的方案,理由是,你可以一个地方部署dev的代码,另一个地方部署release分支的东西,我相信很多团队都是这么做的。其实还有一个理由,刚才说到启动的环境不同,比如在NodeJs环境中我的production会启用cluster,而dev模式我只需要www就可以了,再比如一些log啊,一些资源的conpress level也是不一样的,加载的效率,以及中间件的数量会影响到程序的性能。
这个现象在Rails中其实很明显,production中很多东西和development的东西不一样,assets加载,以及中间件数量会非常明显,包括Gemfile中加载的东西也有很多直接不装的。

思考

目前,公司项目中有一个管理后台,限于人员以及开发的周期,其实采用第一种方案是比较优的解决方案,当然我有一个想法,按照production的标准部署代码,但是可以切换加载不同的js来达到切换数据源。
今天注意到了写的webpack脚本在npm run watch的时候打出来的bundle和npm run build中加载的数据源的地址不一样,因为前端pack的时候也用到了process.env.NODE_ENV所以,我想,目前很多都是只在body中加载一个整个bundle文件就可以运行整个app了,而且其实可以打出不同分支的代码的bundle。可以使用url中带有的参数进行识别,然后去渲染不同的bundle就可以区分,并且可以渲染出不同分支的代码。

你可能感兴趣的:(关于生产环境以及测试环境的一些想法)