昨天，我們讓程式能一路從 CI 跑進 CD，上到 EC2，自動得很順。
但有沒有發現，只要有人 push 到 main，佈署就會直接觸發？
這在 side project 沒什麼，放到 production 就是災難。

想像一下：半夜你只是修個 README，結果 pipeline 直接把伺服器重啟一遍。
這種情境，正是 Deployment Protection Rule 要解決的問題。

什麼是 Environment 保護？

GitHub Workflow 的 job 可以綁定到一個 environment，例如：

jobs:
  deploy:
    environment: prod

當你在 repo 設定 Settings → Environments → prod，就能規定：

• 誰有權批准這個部署
• 是否要加等待時間
• 部署紀錄要不要加審計

效果就是：即使程式碼已經 merge 到 main，佈署還需要有人按下「Approve」，才會繼續跑。

為什麼這麼重要？

• 防手滑：就算不小心 push 了，也不會立刻炸 production。
• 雙重守門：Day.6 的 PR Flow 保證「程式碼能不能進 main」，而這一層是「main 的程式碼能不能進 production」。 (介紹傳送門)
• 審計清楚：誰批准的、什麼時間、佈署了哪個 commit，全部有紀錄。

PR Flow 是城門口的守衛，檢查裝備合不合格；
Deployment Protection Rule 則是副本傳送門前的團長，最後一句話是「可以開怪了」。

實作步驟

1. 新增 Environment
   到 Repo → Settings → Environments → New environment，名稱輸入 prod。
   

2. 設定保護規則
   在 prod 裡開啟「Required reviewers」，選擇必須批准部署的人。
   也可以加上 等待時間（Wait timer），或限制某些分支才允許部署。
   

3. 綁定到 workflow
   在你的 cd.yml 裡，把 deploy job 綁上 environment：

jobs:
  deploy:
    environment: prod
    runs-on: ubuntu-latest
    steps:
      # ...你的 deploy 步驟

4. 觀察效果
   下次 push 到 main，workflow 會跑到 deploy job，然後卡住，顯示：
   "Waiting for review"。
   只有被指定的 reviewer 點「Approve and deploy」，工作才會繼續。
   

結論

Pull Request Flow + Branch Protection 確保「程式碼能不能進 main」。
Deployment Protection Rule 則是確保「main 的程式碼能不能真正佈署」。

這是雙重守門機制：

• 前者是城門守衛，檢查裝備是否合格。
• 後者是副本團長，按下「可以開怪」的剎車鍵。

這樣，即使 CI/CD 自動化飛快，我們仍能在最後一步踩住剎車，讓部署不再是單行道。

自動化不是放飛，而是能快能停，速度與安全同時握在手裡。