起因
区分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就可以区分，并且可以渲染出不同分支的代码。
