在軟體業，星期五傍晚發佈新版本的，不是無知，就是滿滿的惡意。

業界有一種都市傳說，說什麼敏捷開發就是要能隨時隨地、一天部署十幾次。聽那些沒上過產線的網紅在那邊吹牛就算了，如果你的同事在星期五下午五點，笑著按下了 Merge 按鈕，然後拍拍屁股下班去過週末，拜託你封鎖他。這種行為不叫 Continuous Deployment，這叫自殺還拉大家一起死。

大廠的產線最怕的就是「非預期的狀態變更」。

阿姨年輕待過一間公司，有一個美國時區的 BE，最喜歡在他們那邊的星期五傍晚（台灣時間的週六凌晨）把一堆沒有經過完整 Regression Test 的 Code 倒進主線。他的理由很冠冕堂皇：「我想在週末前把這張 Ticket close 掉。」

結果呢？那個 PR 帶了一個極度隱蔽的 Memory Leak。台灣時間週六早上八點，系統的 Pod 開始連環 OOM 重啟，Load Balancer 直接報 502。我們整個台灣團隊週末被 On-call 挖起來通靈查 Bug，美國同事完全找不到人呢。

面對這種自私的內鬼，不要奢望用團隊文化或是道德勸說來約束他們。產線上的防呆機制（Poka-Yoke），就是要把「不該發生的操作」在物理上直接拔除。

我們必須在 CI/CD 系統裡，導入死硬的「部署凍結（Deployment Freeze）」機制。

強制實作 Time-based Branch Protection
不管你用的是 GitHub Actions 還是 GitLab CI，我們直接在 Pipeline 裡寫死時間鎖。只要是星期五下午 4 點（依各時區動態計算）到星期一早上 9 點發起的 Merge Request，CI 直接 Fail

name: Friday Freeze Gate
on: [pull_request]

jobs:
  block_weekend_merges:
    runs-on: ubuntu-latest
    steps:
      - name: check time
        run: |
          DAY_OF_WEEK=$(date +%u)
          HOUR=$(date +%H)
          if [ "$DAY_OF_WEEK" -eq 5 ] && [ "$HOUR" -ge 16 ]; then
            echo "Don't merge code on Friday"
            exit 1
          fi