核心理念#

要建立從 Dev 到 Ops 的快速且可靠的工作流，我們必須確保在價值流的每個階段都使用類生產環境（production-like environments）。這些環境必須以自動化方式建立，理想上可按需求從版本控制中的腳本和設定資訊產生，完全自助服務，不需要 Operations 的手動介入。

我們的目標是能夠根據版本控制中的內容，重建整個生產環境。

案例：Enterprise Data Warehouse 的教訓#

Em Campbell-Pretty 在一家澳洲大型電信公司領導一個兩億美元的企業資料倉儲計畫。該計畫有十個工作流，全部使用瀑布式流程，且全部嚴重落後進度。

轉型為 Agile 一年後，改善仍然有限。在一次回顧會議中，團隊發現最能提升生產力的事情是「改善環境的可用性」——開發團隊經常需要等待長達八週才能取得環境。

自動化環境建立流程後，他們發現了驚人的事實：只有 50% 的原始碼在開發和測試環境中與生產環境一致。透過將所有變更放入版本控制並自動化環境建立，取得正確環境的時間從八週縮短到一天。

按需建立開發、測試與生產環境#

環境建立緩慢與不一致是造成混亂、破壞性軟體發布的主要原因之一。我們希望開發者能在自己的工作站上執行類生產環境，按需建立且完全自助。

可以使用自動化工具實現這一目標：

• 複製虛擬化環境（例如 VMware 映像、Vagrant 腳本、Amazon AMI）
• 從裸機自動化建立（例如 PXE install）
• 使用 Infrastructure as Code 工具（例如 Puppet、Chef、Ansible、Salt）
• 從虛擬映像或容器組裝（例如 Vagrant、Docker）
• 在公有雲或 PaaS 中啟動（例如 AWS、Google App Engine、OpenStack）

這樣做的好處是多方面的：

• Operations：快速建立新環境，自動化確保一致性，減少繁瑣且易出錯的手動工作
• Development：能在工作站上重現生產環境的必要部分，在最早階段發現並修復問題
• 開發者可以完全控制自己的環境，安全地重現、診斷和修復缺陷

建立整個系統的單一真實來源（Single Repository of Truth）#

版本控制不僅是開發者的工具，更是價值流中所有人的工具，包括 QA、Operations 和 Infosec。我們必須將以下所有資產納入共用的版本控制倉庫：

• 所有應用程式碼和相依性
• 建立資料庫 schema 和參考資料的腳本
• 所有環境建立工具和 artifact（例如 VMware/AMI 映像、Puppet/Chef recipes）
• 建立容器的檔案（例如 Docker 定義檔）
• 所有自動化測試和手動測試腳本
• 支援程式碼打包、部署、資料庫遷移的腳本
• 所有專案 artifact（需求文件、部署程序、發布說明等）
• 所有雲端設定檔（例如 AWS CloudFormation、Azure DSC）
• 任何支援多個服務的基礎設施設定

根據 Puppet Labs 的 2014 State of DevOps Report，Ops 使用版本控制是 IT 績效和組織績效的最高預測指標——甚至比 Dev 使用版本控制更具預測力。這是因為環境中的可設定項目數量級遠超過程式碼本身。

讓基礎設施更容易重建而非修復#

當我們能夠快速重建和重新建立應用程式與環境時，出問題時可以直接重建，而非嘗試修復。

Bill Baker（Microsoft 傑出工程師）有一句經典比喻：

過去我們把伺服器當寵物——為它們取名字，生病時細心照顧。現在伺服器像牛——編號管理，生病就淘汰。

不可變基礎設施（Immutable Infrastructure）#

這種模式禁止手動修改生產環境——唯一進行變更的方式是將修改放入版本控制，然後從頭重建程式碼和環境。這樣做可以：

• 防止任何未受控的變異滲入生產環境
• 系統性地減少基礎設施偏離已知良好狀態的途徑
• 避免 configuration drift、fragile artifacts、snowflakes 等問題

Netflix 的 AWS 實例平均壽命為二十四天，其中 60% 不到一週。這種頻繁替換確保了環境的一致性。

修改「完成」的定義：納入在類生產環境中執行#

當環境可以按需建立且一切都在版本控制中後，我們要確保這些環境被用於開發的日常工作中。

新的「完成」定義：在每個開發迭代結束時，我們需要擁有已整合、已測試、可運作且可交付的程式碼，並且在類生產環境中展示運行。

這帶來的好處包括：

• 大部分整合程式碼與環境的工作在日常工作中完成，而非等到發布末期
• 到專案結束時，程式碼已在類生產環境中成功部署和執行數百甚至數千次
• 在前生產環境中使用與生產環境相同的監控、日誌和部署工具，建立熟悉度和經驗
• 大幅降低生產環境部署風險，消除通常在專案後期才被發現的運維和安全缺陷

結論#

從 Development 到 Operations 的快速工作流要求任何人都能按需取得類生產環境。透過讓開發者從軟體專案最早期就使用類生產環境，我們大幅降低了後期生產問題的風險。將所有生產 artifact 放入版本控制，建立了「單一真實來源」，讓我們能以快速、可重複、有文件記錄的方式重建整個生產環境。讓基礎設施更容易重建而非修復，使問題解決更快、擴充容量更容易。