隨選環境與基礎設施即程式碼

🎯 什麼情境該想到我

當你「要一個能測的環境得先開單、等 Ops 好幾週，等到了還跟生產環境對不起來」的時候。

⚙️ 怎麼用（步驟 / 公式）

意圖：讓開發者能在自己的工作站上，隨選、自助地跑起類生產環境，在日常工作中就持續驗證程式碼品質。

做法要點：

• 不要只把生產環境的規格寫在文件或 wiki 上，而是建立一套共用的建置機制（common build mechanism），用它產生所有環境——development、test、production 都由同一套產生。
• 判準：任何人都能在幾分鐘內拿到類生產環境，不必開單（without opening up a ticket），更不必等好幾週。
• 把「已知良好、穩定、安全、風險已降低」的環境定義下來並自動化；所有需求不是放在文件或某個人腦袋裡，而是編碼在自動化環境建置流程中。
• 六種可用的自動化手段（任選其一或全部）：
  1. 複製虛擬化環境（VMware image、跑 Vagrant script、在 EC2 開 Amazon Machine Image）
  2. 從「bare metal」開始的自動化環境建立流程（例如從 baseline image 做 PXE install）
  3. 使用「infrastructure as code」組態管理工具（Puppet、Chef、Ansible、Salt、CFEngine 等）
  4. 使用自動化作業系統組態工具（Solaris Jumpstart、Red Hat Kickstart、Debian preseed）
  5. 由一組虛擬映像檔或容器組裝出環境（Vagrant、Docker）
  6. 在公有雲（AWS、Google App Engine、Microsoft Azure）、私有雲或其他 PaaS（OpenStack、Cloud Foundry）上開新環境
• 給開發者一個他完全掌控的環境，讓他能安全隔離於生產服務與共用資源之外，快速重現、診斷、修掉缺陷，還能拿環境與建立環境的基礎設施程式碼做實驗。

原文：「By doing this, anyone can get production-like environments in minutes, without opening up a ticket, let alone having to wait weeks.」（L4653–4654）

原文：「All our requirements are embedded, not in documents or as knowledge in someone’s head, but codified in our automated environment build process.」（L4658–4660）

🧪 我實際套用的紀錄

• （待填）

⚠️ 注意 / 什麼時候不適用

• 環境建得出來還不夠：若不強制「開發者實際在類生產環境跑自己的碼」，這套機制會閒置，所以書中把它寫進修改完成的定義。
• 環境本身也是會腐化的資產，必須跟著版本控管一切、不可變基礎設施一起做，否則生產環境仍會靠手動變更漂移。
• 建置機制若不是「單一共用」的，dev/test/prod 各做各的，就退回「測試環境配置錯誤或與生產差太多」的老問題。

🔗 相關工具

• 版本控管一切（環境建置工具與產物必須全部進版控，隨選環境才可重現）
• 不可變基礎設施（有了隨選重建能力，才做得到「重建比修復容易」）
• 修改完成的定義（把「在類生產環境示範過」寫進 done，才會真的去用這些環境）
• 工具-部署管線與持續交付（隨選環境是部署管線最底層的基礎建設）
• DevOps手冊