盡可能的保持開發，預發布，線上環境相同
從以往經驗來看，開發環境（即開發人員的本地部署）和線上環境（外部用戶訪問的真實部署）之間存在著很多差異。這些差異表現在以下三個方面：
- 時間差異：開發人員正在編寫的代碼可能需要幾天，幾周，甚至幾個月才會上線。
- 人員差異：開發人員編寫代碼，運維人員部署代碼。
- 工具差異：開發人員或許使用 Nginx，SQLite，OS X，而線上環境使用 Apache，MySQL 以及 Linux。
12-Factor 應用想要做到持續部署就必須縮小本地與線上差異。
再回頭看上面所描述的三個差異:
- 縮小時間差異：開發人員可以幾小時，甚至幾分鐘就部署代碼。
- 縮小人員差異：開發人員不只要編寫代碼，更應該密切參與部署過程以及代碼在線上的表現。
- 縮小工具差異：盡量保證開發環境以及線上環境的一致性。
上述總結：
| 對比 | 傳統應用 | 12-Factor 應用 |
|---|---|---|
| 每次部署間隔 | 數周 | 幾小時 |
| 開發人員 vs 運維人員 | 不同的人 | 相同的人 |
| 開發環境 vs 線上環境 | 不同 | 盡量接近 |
后端服務是保持開發與線上等價的重要部分
例如數據庫，隊列系統，以及緩存。許多語言都提供了簡化獲取后端服務的類庫，例如不同類型服務的適配器。下列表格提供了一些例子。
| 類型 | 語言 | 類庫 | 適配器 |
|---|---|---|---|
| 數據庫 | Ruby/Rails | ActiveRecord | MySQL, PostgreSQL, SQLite |
| 隊列 | Python/Django | Celery | RabbitMQ, Beanstalkd, Redis |
| 緩存 | Ruby/Rails | ActiveSupport::Cache | Memory, filesystem, Memcached |
開發人員有時會覺得在本地環境中使用輕量的后端服務具有很強的吸引力，而那些更重量級的健壯的后端服務應該使用在生產環境。例如，本地使用 SQLite 線上使用 PostgreSQL；又如本地緩存在進程內存中而線上存入 Memcached。
12-Factor 應用的開發人員應該反對在不同環境間使用不同的后端服務 ，即使適配器已經可以幾乎消除使用上的差異。
這是因為，不同的后端服務意味著會突然出現的不兼容，從而導致測試、預發布都正常的代碼在線上出現問題。這些錯誤會給持續部署帶來阻力。從應用程序的生命周期來看，消除這種阻力需要花費很大的代價。
與此同時，輕量的本地服務也不像以前那樣引人注目。借助于 Homebrew，apt-get 等現代的打包系統，諸如Memcached、PostgreSQL、RabbitMQ 等后端服務的安裝與運行也并不復雜。此外，使用類似 Chef 和 Puppet 的聲明式配置工具，結合像 Vagrant 這樣輕量的虛擬環境就可以使得開發人員的本地環境與線上環境無限接近。與同步環境和持續部署所帶來的益處相比，安裝這些系統顯然是值得的。
不同后端服務的適配器仍然是有用的，因為它們可以使移植后端服務變得簡單。但應用的所有部署，這其中包括開發、預發布以及線上環境，都應該使用同一個后端服務的相同版本。
很多公司因為分工很明確，代碼是開發寫的，生產環境和運行是運維的事情。作為負責開發，要從需求的正確性到往后，整個代碼的正確性都是應該負責的。機器太慢的情況已經比較少見了，所以我們盡量保證開發的環境和運行的環境是一樣的。持續集成很重要，其實很多人，特別是小團隊可能會覺得持續集成，搞測試是一件很煩的事情。其實不是的，你要很簡易的搭一個不斷地跑測試的服務器是很重要的。它會往這個服務發一個HTTP的包，不管成功、失敗會發出來一份文件。這種情況回歸測試是很重要的，遇到一個bug，寫一個測試能夠重現它。下一次這個測試會直接告訴你怎樣做的，將來這個代碼不可維護了。任何的改動破壞到原來的東西，測試都會跑不過。環境等價是特別重要的一點。如果每個系統都往文件里面寫的話，每一個日志都會分攤在不同的地方，一旦出了問題，你都不知道該去看哪里的日志了。
參考：
