開發環境（dev)：開發環境是程序猿們專門用於開發的服務器，配置可以比較隨意，為了開發調試方便，一般打開全部錯誤報告。
測試環境(test)：一般是克隆一份生產環境的配置，一個程序在測試環境工作不正常，那么肯定不能把它發布到生產機上。
灰度環境（pre）：灰度環境，外部用戶可以訪問，但是服務器配置相對低，其它和生產一樣。 <很多企業將test環境作為Pre環境 >
生產環境（prod）：是值正式提供對外服務的，一般會關掉錯誤報告，打開錯誤日志。
三個環境也可以說是系統開發的三個階段：開發->測試->上線，其中生產環境也就是通常說的真實環境。
分成多個環境的原因
大多數人都知道四個環境指的是什么，但是很多人卻不知道為什么要這么區別，甚至為了省事就只有dev和pro環境。如果項目沒有上線之前沒有問題，如果項目上線之后就會有非常麻煩的事情發生。下面我們針對這四種環境，來分析一下對應的各種場景。
dev+pro
如果我們只有dev和pro環境，pro突然發現bug，需要緊急處理，只有兩個環境，這個時候我們要如何解決呢？？？
首先dev現在已經更新到1.1.0，而pro現在才1.0.0，所以這個時候我們需要重新創建一個brunch分支，這邊我們可以叫做1.0.0.1,然后修改代碼之后需要放到dev環境上面進行測試，這個時候就會變成如下所示狀態：
然后測試通過之后，我們需要將1.0.0.1發布到pro環境，然后合並1.0.0.1的代碼到1.1.0中，最后將dev環境修改為1.1.1，如下所示：
在dev1.0.0.1測試期間，所以開發工作全部得停止，必須等測試通過發布到生產上面才可以，如果僅僅只有兩個環境，代價實在是太大了！！
dev+test+pro
如果我們多了一個test環境情況就會好很多了，比如上面說所的問題，我們就可以這么來處理。
我們可以在test1.0.0上面直接修改，修改后的版本是1.0.0.1，測試通過之后直接發布到pro環境即可。然后再將test中1.0.0.1代碼合並到1.1.0，最后dev的版本升一級就可以了。
這樣的好處就是不會影響dev開發環境，不管怎么修改test，都不會造成dev暫停。
dev+test+pre+pro
如果test環境和pro環境版本不同步，還是會有問題存在，比如test環境在測試1.0.1版本的代碼而生產上面運行的是pro環境的代碼，這個時候pro出現問題修改的時候就會比較麻煩。
這個時候和之前的做法一樣，創建一個新的brunch分支（1.0.0.1）然后在1.0.0.1中修復bug，然后發布到test最新版本中，測試通過之后發布到pro環境中。然后就是復雜的合代碼操作了，將1.0.0.1代碼合並到1.0.1中，將dev的1.1.0添加上修復的代碼變成1.1.1。
這種情況下，首先在test測試期間，1.0.1的測試工作會停止，其次步驟太繁瑣，所以這邊我們新增了pre環境。
我們只要保證pre的版本和pro環境的版本一致，就可以解決上面的問題了。如上圖所示，我們只需要在pre的1.0.0環境上面修復bug就可以了，修復好之后發布到pro環境就可以了，然后將代碼同步到test和dev中即可。
這樣以后不管pro遇到什么問題，我們都可以按照上面的步驟來解決。
總結：
四個環境最大的好處就是各司其職，既不會影響開發，也不會影響測試工作。而且增加一個pre環境也可以盡可能的模仿pro的真實環境，讓測試結果更加准確。
Ref:
http://spacebug.com/effective_development_environments/
一開始，你可能覺得你只需要一個環境，well, at most two: 一個Dev環境（aka ur PC） + one server. 但是隨着項目的發展，可能需要更多的環境，那它們是什么，又有什么用處呢？ 1. 環境的定義 Environment – In hosted software (eg web site/application, database not shrinkwrap software) development, environment refers to a server tier designated to a specific stage in a release process. 2. a typical product release cycle Development Environment This is where the software is developed. In some situations this could be the developer’s desktop, in other situations this would be a server shared by several developers working together on the same project. This environment should resemble the production environment as much as possible to prevent issues were the software acts differently on production. Testing Environment After the application was developed to an agreed stage it is released to the testing environment. This is where the testers ensures the quality of the application, open bugs and review bug fixes. This environment must resemble the production environment accurately, because this is the last safe place to find and fix environment-related bugs. User Acceptance Test Environment (UAT) In a client-vendor projects, the software then moves from internal testing (done by the vendor’s testers) to client testing. This is where the client’s testers verify the quality of the application and send issues for the vendor to fix. This is also where the client assesses the application and can request changes to better fit his requirements. Some clients do not require UAT. Staging Environment (AKA pre production) The staging site is used to assemble, test and review new versions of a website before it goes into production. The staging phase of the software lifecycle is often tested on hardware that mirrors hardware used in the production environment. The staging site is often different from the development site, and provides a final QA zone that is separate from the development or production environments. Production Environment This is where the application goes out to the world and become production. Content can be updated from the staging environment in to Production Environment, when available, as well as new application functionality and bug fixes release from UAT or staging environment. So, how many do I need? Note that small to medium software projects might not need all environments, on the other hand, from time to time you might want to add additional environments (for example to accommodate separate concurrent versions of the same application, or stress/load environment) To make things even more complex, you might not need to have all these environments up and running on the same time – you might want to buy the Staging Environment hardware only after the first release to the Testing Environment, in order to save money. 3. Conclusion The main purpose of these environments is to improve the development, testing, and release processes in client-server applications. There is no magic number of environments that make everything work OK. hopefully, with this article, you can determine what best suites your project. It is the job of the architect, project manager, operations manager or change manager (pick one) to determine which environments are needed, to make sure these environments are in place and on time, in order to make the developers, testers, and client's life easier and happier.
·