web專案開發中，有三個實踐對於專案成功是非常重要的：
1. staging servers
2. Version control workflows
3. Tested, repeatable deployments.
Staging Servers:
什麼是Staging server呢？基本想法是 staging=production-users。如果你是facebook,google那麼你可能早已經有了成熟的工作流程，你已經有了一些具備多級staging/production的系統，你可以動態地更改他們。你已經有了一些天才為你工作，聽聽他們怎麼想就可以了。這篇文章適合於那些沒有為自己工作的天才的老闆們，對於那些處於“要麼在開發人員電腦上執行”，“要麼在生產環境中執行”狀態的團隊。
為什麼我們需要staging servers? 任何可能在生產環境會down機的情況都需要再staging server上首先發生！正是因為這個原因，你總是希望staging server環境和production server環境越接近越好。如果生產環境處理信用卡業務，那麼staging環境同樣也要處理信用卡。這意味著如果你的支付閘道器配置收到影響，那麼你將在staging server上發現這個情況，而不是放到production server上才發現。如果你的production server使用ruby1.9,那麼你的staging server也要使用ruby1.9.如果你的production server上使用memcache並放在12345埠，那麼staging server上同樣在12345埠上使用memcache.
配置一臺staging server是很簡單的。如果對你來說不簡單的話，那麼意味著你的infrastructure本身就存在問題了，只是你不知道而已：你可能是長時間地對你的production server粗製濫造，比如手工ssh到你的系統中,調整你的配置而沒有任何關於你做了什麼的log。你沒有一個歸檔的過程或者自動化的指令碼來從頭建立你的production server.如果你有那個如何建立你的production server的歸檔記錄或者自動化建立指令碼，那麼你一定可以在一個小時內把staging server搭建起來，而這個stagingserver基本上和production server是一樣的。
大部分人可能沒有能力這樣做如果他們沒有仔細思考這個問題的話。這是可以解決的，而且應該解決。這有實質性的好處：如果你有一個可以重複的過程來provisioning一個產品環境的話，那麼有一天如果發生了系統崩潰，你將有信心在很快執行一個流程恢復系統。信心是很重要的，因為一旦發生災難，你將無所適從，而無所適從的情況下，你是很難免於犯錯的。所以一切有備無患。
保持你的伺服器配置在一個指令碼中比在伺服器上分別配置多處（比如/etc/environment,/etc/crontab,/usrlocal/nginx/conf/apps/appname.conf etc)的好處是這個指令碼可以放在版本控制系統中。你的cron jobs?如果他們本身也被版本控制，那麼你將有你的系統變更的過程記錄。
在你準備好了能夠重複生產你的staging environment時，你可能希望做一個小小的修改。很多公司可能不希望他們的staging environment放到公網上，因為這樣的話，客戶不會在成熟之前看到系統的墨陽，而嚴重的問題永遠不會影響到外面的世界。有很多種方式來這樣做：理想地，你只要在防火牆上配置規則，任何從網際網路上來的能夠進入到你的staging environment.
我的staging environment僅僅包含ngix的一片小程式碼，它拒絕任何人的訪問，除非一個特定的host被允許。這將會break和外部server的整合，比如twilio,spreedly，他們是需要callback的。所以我就對這兩個url做一個例外，允許他們訪問。
另外一個問題是：你如何populate一些資料到staging server上去呢？我通常使用seed指令碼，手工增加一些資料。你也可以dump production DB並且載入到staging DB上去。