目錄
簡介
一、基準代碼
二、依賴
三、配置
四、後端配置
五、建構、釋出、運作
六、程序
七、端口綁定
八、并發
九、易處理
十、開發與線上環境等價
十一、日志
十二、程序管理
當今雲原生技術是雲計算發展的主流，基于雲原生技術有利于各組織在公有雲、私有雲和混合雲等新型動态環境中，建構和運作可彈性擴充的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。
這些技術能夠建構容錯性好、易于管理和便于觀察的松耦合系統。結合可靠的自動化手段，雲原生技術使工程師能夠輕松地對系統作出頻繁和可預測的重大變更。
雲原生技術雖然好，但對于如何設計開發好雲原生應用卻缺乏普适性的實踐與方法論，本文的 12factor 是目前主流的最佳開發實踐之一。
- GitHub - heroku/12factor https://github.com/heroku/12factor
雲原生應用最佳開發實踐之十二原則（12-factor）一、基準代碼二、依賴三、配置四、後端配置五、建構、釋出、運作六、程式七、端口綁定八、并發九、易處理十、開發與線上環境等價十一、日志十二、程式管理
本文的貢獻者參與過數以百計的應用程式的開發和部署，并通過 Heroku 平台間接見證了數十萬應用程式的開發，運作以及擴充的過程。
本文綜合了我們關于 SaaS 應用幾乎所有的經驗和智慧，是開發此類應用的理想實踐标準，并特别關注于應用程式如何保持良性成長，開發者之間如何進行有效的代碼協作，以及如何避免軟體污染 。
我們的初衷是分享在現代軟體開發過程中發現的一些系統性問題，并加深對這些問題的認識。我們提供了讨論這些問題時所需的共享詞彙，同時使用相關術語給出一套針對這些問題的廣義解決方案。本文格式的靈感來自于 Martin Fowler 的書籍： 《Patterns of Enterprise Application Architecture ， Refactoring 》。
簡介
如今，軟體通常會作為一種服務來傳遞，它們被稱為網絡應用程式，或軟體即服務（SaaS）。12-Factor 為建構如下的 SaaS 應用提供了方法論：
- 使用标準化流程自動配置，進而使新的開發者花費最少的學習成本加入這個項目。
- 和作業系統之間盡可能的劃清界限，在各個系統中提供最大的可移植性。
- 适合部署在現代的雲計算平台，進而在伺服器和系統管理方面節省資源。
- 将開發環境和生産環境的差異降至最低，并使用持續傳遞實施靈活開發。
- 可以在工具、架構和開發流程不發生明顯變化的前提下實作擴充。
這套理論适用于任意語言和後端服務（資料庫、消息隊列、緩存等）開發的應用程式。
讀者應該是哪些人？
任何 SaaS 應用的開發人員。部署和管理此類應用的運維工程師。
一、基準代碼
一份基準代碼（Codebase），多份部署（deploy）
12-Factor應用(譯者注：應該是說一個使用本文概念來設計的應用，下同)通常會使用版本控制系統加以管理，如Git, Mercurial, Subversion。一份用來跟蹤代碼所有修訂版本的資料庫被稱作 代碼庫（code repository, code repo, repo）。
在類似 SVN 這樣的集中式版本控制系統中，基準代碼 就是指控制系統中的這一份代碼庫；而在 Git 那樣的分布式版本控制系統中，基準代碼 則是指最上遊的那份代碼庫。
基準代碼和應用之間總是保持一一對應的關系：
- 一旦有多個基準代碼，就不能稱為一個應用，而是一個分布式系統。分布式系統中的每一個元件都是一個應用，每一個應用可以分别使用 12-Factor 進行開發。
- 多個應用共享一份基準代碼是有悖于 12-Factor 原則的。解決方案是将共享的代碼拆分為獨立的類庫，然後使用 依賴管理 政策去加載它們。
盡管每個應用隻對應一份基準代碼，但可以同時存在多份部署。每份 部署 相當于運作了一個應用的執行個體。通常會有一個生産環境，一個或多個預釋出環境。此外，每個開發人員都會在自己本地環境運作一個應用執行個體，這些都相當于一份部署。
所有部署的基準代碼相同，但每份部署可以使用其不同的版本。比如，開發人員可能有一些送出還沒有同步至預釋出環境；預釋出環境也有一些送出沒有同步至生産環境。但它們都共享一份基準代碼，我們就認為它們隻是相同應用的不同部署而已。
二、依賴
顯式聲明依賴關系（ dependency ）
大多數程式設計語言都會提供一個打包系統，用來為各個類庫提供打包服務，就像 Perl 的 CPAN 或是 Ruby 的 Rubygems 。通過打包系統安裝的類庫可以是系統級的（稱之為 "site packages"），或僅供某個應用程式使用，部署在相應的目錄中（稱之為 "vendoring" 或 "bunding"）。
12-Factor規則下的應用程式不會隐式依賴系統級的類庫。 它一定通過 依賴清單 ，确切地聲明所有依賴項。此外，在運作過程中通過 依賴隔離 工具來確定程式不會調用系統中存在但清單中未聲明的依賴項。這一做法會統一應用到生産和開發環境。
例如， Ruby 的 Bundler 使用
Gemfile
作為依賴項聲明清單，使用
bundle exec
來進行依賴隔離。Python 中則可分别使用兩種工具 -- Pip 用作依賴聲明， Virtualenv 用作依賴隔離。甚至 C 語言也有類似工具， Autoconf 用作依賴聲明，靜态連結庫用作依賴隔離。無論用什麼工具，依賴聲明和依賴隔離必須一起使用，否則無法滿足 12-Factor 規範。
顯式聲明依賴的優點之一是為新進開發者簡化了環境配置流程。新進開發者可以檢出應用程式的基準代碼，安裝程式設計語言環境和它對應的依賴管理工具，隻需通過一個 建構指令 來安裝所有的依賴項，即可開始工作。例如，Ruby/Bundler 下使用
bundle install
，而 Clojure/Leiningen 則是
lein deps
。
12-Factor 應用同樣不會隐式依賴某些系統工具，如 ImageMagick 或是
curl
。即使這些工具存在于幾乎所有系統，但終究無法保證所有未來的系統都能支援應用順利運作，或是能夠和應用相容。如果應用必須使用到某些系統工具，那麼這些工具應該被包含在應用之中。
三、配置
在環境中存儲配置
通常，應用的 配置 在不同 部署 (預釋出、生産環境、開發環境等等)間會有很大差異。這其中包括：
- 資料庫，Memcached，以及其他 後端服務 的配置
- 第三方服務的證書，如 Amazon S3、Twitter 等
- 每份部署特有的配置，如域名等
有些應用在代碼中使用常量儲存配置，這與 12-Factor 所要求的代碼和配置嚴格分離顯然大相徑庭。配置檔案在各部署間存在大幅差異，代碼卻完全一緻。
判斷一個應用是否正确地将配置排除在代碼之外，一個簡單的方法是看該應用的基準代碼是否可以立刻開源，而不用擔心會暴露任何敏感的資訊。
需要指出的是，這裡定義的"配置"并不包括應用的内部配置，比如 Rails 的
config/routes.rb
，或是使用 Spring 時 代碼子產品間的依賴注入關系 。這類配置在不同部署間不存在差異，是以應該寫入代碼。
另外一個解決方法是使用配置檔案，但不把它們納入版本控制系統，就像 Rails 的
config/database.yml
。這相對于在代碼中使用常量已經是長足進步，但仍然有缺點：總是會不小心将配置檔案簽入了代碼庫；配置檔案的可能會分散在不同的目錄，并有着不同的格式，這讓找出一個地方來統一管理所有配置變的不太現實。更糟的是，這些格式通常是語言或架構特定的。
12-Factor推薦将應用的配置存儲于 環境變量 中（ env vars, env ）。環境變量可以非常友善地在不同的部署間做修改，卻不動一行代碼；與配置檔案不同，不小心把它們簽入代碼庫的機率微乎其微；與一些傳統的解決配置問題的機制（比如 Java 的屬性配置檔案）相比，環境變量與語言和系統無關。
配置管理的另一個方面是分組。有時應用會将配置按照特定部署進行分組（或叫做“環境”），例如Rails中的
development
,
test
, 和
production
環境。這種方法無法輕易擴充：更多部署意味着更多新的環境，例如
staging
或
qa
。随着項目的不斷深入，開發人員可能還會添加他們自己的環境，比如
joes-staging
，這将導緻各種配置組合的激增，進而給管理部署增加了很多不确定因素。
12-Factor 應用中，環境變量的粒度要足夠小，且相對獨立。它們永遠也不會組合成一個所謂的“環境”，而是獨立存在于每個部署之中。當應用程式不斷擴充，需要更多種類的部署時，這種配置管理方式能夠做到平滑過渡。
四、後端配置
把後端服務(backing services)當作附加資源
後端服務是指程式運作所需要的通過網絡調用的各種服務，如資料庫（MySQL，CouchDB），消息/隊列系統（RabbitMQ，Beanstalkd），SMTP 郵件發送服務（ Postfix），以及緩存系統（Memcached）。
類似資料庫的後端服務，通常由部署應用程式的系統管理者一起管理。除了本地服務之外，應用程式有可能使用了第三方釋出和管理的服務。示例包括 SMTP（例如 Postmark），資料收集服務（例如 New Relic 或 Loggly），資料存儲服務（如 Amazon S3），以及使用 API 通路的服務（例如 Twitter, Google Maps, Last.fm）。
12-Factor 應用不會差別對待本地或第三方服務。 對應用程式而言，兩種都是附加資源，通過一個 url 或是其他存儲在 配置 中的服務定位/服務證書來擷取資料。12-Factor 應用的任意 部署 ，都應該可以在不進行任何代碼改動的情況下，将本地 MySQL 資料庫換成第三方服務（例如 Amazon RDS）。類似的，本地 SMTP 服務應該也可以和第三方 SMTP 服務（例如 Postmark ）互換。上述 2 個例子中，僅需修改配置中的資源位址。
每個不同的後端服務是一份資源 。例如，一個 MySQL 資料庫是一個資源，兩個 MySQL 資料庫（用來資料分區）就被當作是 2 個不同的資源。12-Factor 應用将這些資料庫都視作 附加資源 ，這些資源和它們附屬的部署保持松耦合。
部署可以按需加載或解除安裝資源。例如，如果應用的資料庫服務由于硬體問題出現異常，管理者可以從最近的備份中恢複一個資料庫，解除安裝目前的資料庫，然後加載新的資料庫 -- 整個過程都不需要修改代碼。
五、建構、釋出、運作
嚴格分離建構和運作
基準代碼 轉化為一份部署(非開發環境)需要以下三個階段：
- 建構階段 是指将代碼倉庫轉化為可執行包的過程。建構時會使用指定版本的代碼，擷取和打包 依賴項，編譯成二進制檔案和資源檔案。
- 釋出階段 會将建構的結果和目前部署所需 配置 相結合，并能夠立刻在運作環境中投入使用。
- 運作階段 （或者說“運作時”）是指針對標明的釋出版本，在執行環境中啟動一系列應用程式 程序。
12-factor 應用嚴格區分建構，釋出，運作這三個步驟。 舉例來說，直接修改處于運作狀态的代碼是非常不可取的做法，因為這些修改很難再同步回建構步驟。
部署工具通常都提供了釋出管理工具，最引人注目的功能是退回至較舊的釋出版本。比如， Capistrano 将所有釋出版本都存儲在一個叫
releases
的子目錄中，目前的線上版本隻需映射至對應的目錄即可。該工具的
rollback
指令可以很容易地實作回退版本的功能。
每一個釋出版本必須對應一個唯一的釋出 ID，例如可以使用釋出時的時間戳（
2011-04-06-20:32:17
），亦或是一個增長的數字（
v100
）。釋出的版本就像一本隻能追加的賬本，一旦釋出就不可修改，任何的變動都應該産生一個新的釋出版本。
新的代碼在部署之前，需要開發人員觸發建構操作。但是，運作階段不一定需要人為觸發，而是可以自動進行。如伺服器重新開機，或是程序管理器重新開機了一個崩潰的程序。是以，運作階段應該保持盡可能少的子產品，這樣假設半夜發生系統故障而開發人員又捉襟見肘也不會引起太大問題。建構階段是可以相對複雜一些的，因為錯誤資訊能夠立刻展示在開發人員面前，進而得到妥善處理。
六、程序
以一個或多個無狀态程序運作應用
運作環境中，應用程式通常是以一個和多個 程序 運作的。
最簡單的場景中，代碼是一個獨立的腳本，運作環境是開發人員自己的筆記本電腦，程序由一條指令行（例如
python my_script.py
）。另外一個極端情況是，複雜的應用可能會使用很多 程序類型 ，也就是零個或多個程序執行個體。
12-Factor 應用的程序必須無狀态且 無共享 。 任何需要持久化的資料都要存儲在 後端服務 内，比如資料庫。
記憶體區域或磁盤空間可以作為程序在做某種事務型操作時的緩存，例如下載下傳一個很大的檔案，對其操作并将結果寫入資料庫的過程。12-Factor應用根本不用考慮這些緩存的内容是不是可以保留給之後的請求來使用，這是因為應用啟動了多種類型的程序，将來的請求多半會由其他程序來服務。即使在隻有一個程序的情形下，先前儲存的資料（記憶體或檔案系統中）也會因為重新開機（如代碼部署、配置更改、或運作環境将程序排程至另一個實體區域執行）而丢失。
源檔案打包工具（Jammit, django-compressor） 使用檔案系統來緩存編譯過的源檔案。12-Factor 應用更傾向于在 建構步驟 做此動作——正如 Rails資源管道 ，而不是在運作階段。
一些網際網路系統依賴于 “粘性 session ”， 這是指将使用者 session 中的資料緩存至某程序的記憶體中，并将同一使用者的後續請求路由到同一個程序。粘性 session 是 12-Factor 極力反對的。Session 中的資料應該儲存在諸如 Memcached 或 Redis 這樣的帶有過期時間的緩存中。
七、端口綁定
通過端口綁定(Port binding)來提供服務
網際網路應用有時會運作于伺服器的容器之中。例如 PHP 經常作為 Apache HTTPD 的一個子產品來運作，正如 Java 運作于 Tomcat 。
12-Factor 應用完全自我加載 而不依賴于任何網絡伺服器就可以建立一個面向網絡的服務。網際網路應用 通過端口綁定來提供服務 ，并監聽發送至該端口的請求。
本地環境中，開發人員通過類似
http://localhost:5000/
的位址來通路服務。線上上環境中，請求統一發送至公共域名而後路由至綁定了端口的網絡程序。
通常的實作思路是，将網絡伺服器類庫通過 依賴聲明 載入應用。例如，Python 的 Tornado, Ruby 的Thin , Java 以及其他基于 JVM 語言的 Jetty。完全由 使用者端 ，确切的說應該是應用的代碼，發起請求。和運作環境約定好綁定的端口即可處理這些請求。
HTTP 并不是唯一一個可以由端口綁定提供的服務。其實幾乎所有伺服器軟體都可以通過程序綁定端口來等待請求。例如，使用 XMPP 的 ejabberd ， 以及使用 Redis 協定 的 Redis 。
還要指出的是，端口綁定這種方式也意味着一個應用可以成為另外一個應用的 後端服務 ，調用方将服務方提供的相應 URL 當作資源存入 配置 以備将來調用。
八、并發
通過程序模型進行擴充
任何計算機程式，一旦啟動，就會生成一個或多個程序。網際網路應用采用多種程序運作方式。例如，PHP 程序作為 Apache 的子程序存在，随請求按需啟動。Java 程序則采取了相反的方式，在程式啟動之初 JVM 就提供了一個超級程序儲備了大量的系統資源(CPU 和記憶體)，并通過多線程實作内部的并發管理。上述 2 個例子中，程序是開發人員可以操作的最小機關。
在 12-factor 應用中，程序是一等公民。12-Factor 應用的程序主要借鑒于 unix 守護程序模型 。開發人員可以運用這個模型去設計應用架構，将不同的工作配置設定給不同的 程序類型 。例如，HTTP 請求可以交給 web 程序來處理，而常駐的背景工作則交由 worker 程序負責。
這并不包括個别較為特殊的程序，例如通過虛拟機的線程處理并發的内部運算，或是使用諸如 EventMachine, Twisted, Node.js 的異步/事件觸發模型。但一台獨立的虛拟機的擴充有瓶頸（垂直擴充），是以應用程式必須可以在多台實體機器間跨程序工作。
上述程序模型會在系統急需擴充時大放異彩。12-Factor 應用的程序所具備的無共享，水準分區的特性 意味着添加并發會變得簡單而穩妥。這些程序的類型以及每個類型中程序的數量就被稱作 程序構成 。
12-Factor 應用的程序 不需要守護程序 或是寫入 PID 檔案。相反的，應該借助作業系統的程序管理器(例如 systemd ，分布式的程序管理雲平台，或是類似 Foreman 的工具)，來管理 輸出流 ，響應崩潰的程序，以及處理使用者觸發的重新開機和關閉超級程序的請求。
九、易處理
快速啟動和優雅終止可最大化健壯性
12-Factor 應用的 程序 是 易處理（disposable）的，意思是說它們可以瞬間開啟或停止。 這有利于快速、彈性的伸縮應用，迅速部署變化的 代碼 或 配置 ，穩健的部署應用。
程序應當追求 最小啟動時間 。理想狀态下，程序從敲下指令到真正啟動并等待請求的時間應該隻需很短的時間。更少的啟動時間提供了更靈活的 釋出 以及擴充過程，此外還增加了健壯性，因為程序管理器可以在授權情形下容易的将程序搬到新的實體機器上。
程序 一旦接收 終止信号（
SIGTERM
） 就會優雅的終止 。就網絡程序而言，優雅終止是指停止監聽服務的端口，即拒絕所有新的請求，并繼續執行目前已接收的請求，然後退出。此類型的程序所隐含的要求是HTTP請求大多都很短(不會超過幾秒鐘)，而在長時間輪詢中，用戶端在丢失連接配接後應該馬上嘗試重連。
對于 worker 程序來說，優雅終止是指将目前任務退回隊列。例如，RabbitMQ 中，worker 可以發送一個
NACK
信号。Beanstalkd 中，任務終止并退回隊列會在worker斷開時自動觸發。有鎖機制的系統諸如 Delayed Job 則需要确定釋放了系統資源。此類型的程序所隐含的要求是，任務都應該 可重複執行 ， 這主要由将結果包裝進事務或是使重複操作 幂等 來實作。
程序還應當在面對突然死亡時保持健壯，例如底層硬體故障。雖然這種情況比起優雅終止來說少之又少，但終究有可能發生。一種推薦的方式是使用一個健壯的後端隊列，例如 Beanstalkd ，它可以在用戶端斷開或逾時後自動退回任務。無論如何，12-Factor 應用都應該可以設計能夠應對意外的、不優雅的終結。Crash-only design 将這種概念轉化為 合乎邏輯的理論。
十、開發與線上環境等價
盡可能的保持開發，預釋出，線上環境相同
從以往經驗來看，開發環境（即開發人員的本地 部署）和線上環境（外部使用者通路的真實部署）之間存在着很多差異。這些差異表現在以下三個方面：
- 時間差異： 開發人員正在編寫的代碼可能需要幾天，幾周，甚至幾個月才會上線。
- 人員差異： 開發人員編寫代碼，運維人員部署代碼。
- 工具差異： 開發人員或許使用 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 這樣輕量的虛拟環境就可以使得開發人員的本地環境與線上環境無限接近。與同步環境和持續部署所帶來的益處相比，安裝這些系統顯然是值得的。
不同後端服務的擴充卡仍然是有用的，因為它們可以使移植後端服務變得簡單。但應用的所有部署，這其中包括開發、預釋出以及線上環境，都應該使用同一個後端服務的相同版本。
十一、日志
把日志當作事件流
日志 使得應用程式運作的動作變得透明。在基于伺服器的環境中，日志通常被寫在硬碟的一個檔案裡，但這隻是一種輸出格式。
日志應該是 事件流 的彙總，将所有運作中程序和後端服務的輸出流按照時間順序收集起來。盡管在回溯問題時可能需要看很多行，日志最原始的格式确實是一個事件一行。日志沒有确定開始和結束，但随着應用在運作會持續的增加。
12-factor應用本身從不考慮存儲自己的輸出流。 不應該試圖去寫或者管理日志檔案。相反，每一個運作的程序都會直接的标準輸出（
stdout
）事件流。開發環境中，開發人員可以通過這些資料流，實時在終端看到應用的活動。
在預釋出或線上部署中，每個程序的輸出流由運作環境截獲，并将其他輸出流整理在一起，然後一并發送給一個或多個最終的處理程式，用于檢視或是長期存檔。這些存檔路徑對于應用來說不可見也不可配置，而是完全交給程式的運作環境管理。類似 Logplex 和 Fluentd 的開源工具可以達到這個目的。
這些事件流可以輸出至檔案，或者在終端實時觀察。最重要的，輸出流可以發送到 Splunk 這樣的日志索引及分析系統，或 Hadoop/Hive 這樣的通用資料存儲系統。這些系統為檢視應用的曆史活動提供了強大而靈活的功能，包括：
- 找出過去一段時間特殊的事件。
- 圖形化一個大規模的趨勢，比如每分鐘的請求量。
- 根據使用者定義的條件實時觸發警報，比如每分鐘的報錯超過某個警戒線。
十二、程序管理
背景管理任務當作一次性程序運作
程序構成（process formation）是指用來處理應用的正常業務（比如處理 web 請求）的一組程序。與此不同，開發人員經常希望執行一些管理或維護應用的一次性任務，例如：
- 運作資料移植（Django 中的
manage.py migrate
rake db:migrate
- 運作一個控制台（也被稱為 REPL shell），來執行一些代碼或是針對線上資料庫做一些檢查。大多數語言都通過解釋器提供了一個 REPL 工具（
python
perl
irb
rails console
- 運作一些送出到代碼倉庫的一次性腳本。
一次性管理程序應該和正常的 常駐程序 使用同樣的環境。這些管理程序和任何其他的程序一樣使用相同的 代碼 和 配置 ，基于某個 釋出版本 運作。背景管理代碼應該随其他應用程式代碼一起釋出，進而避免同步問題。
所有程序類型應該使用同樣的 依賴隔離 技術。例如，如果Ruby的web程序使用了指令
bundle exec thin start
，那麼資料庫移植應使用
bundle exec rake db:migrate
。同樣的，如果一個 Python 程式使用了 Virtualenv，則需要在運作 Tornado Web 伺服器和任何
manage.py
管理程序時引入
bin/python
。
12-factor 尤其青睐那些提供了 REPL shell 的語言，因為那會讓運作一次性腳本變得簡單。在本地部署中，開發人員直接在指令行使用 shell 指令調用一次性管理程序。線上上部署中，開發人員依舊可以使用ssh或是運作環境提供的其他機制來運作這樣的程序。