「如果能夠做到頻繁發佈，每個發佈版本之間的差異會很小。」——《Continuous Delivery 中文版》

每次教 CI/CD 時，我在授課簡報中都會插入一個問題「CI/CD 提到『持續』，這意味著我們要多『頻繁』的整合與交付呢？」

答案有很多種，其中一個可能是每一次 Commit。

當然，這答案有人會覺得太誇張了。

因為一個 Commit 可能只包含了一行甚至更少的程式碼變更，這樣也要整合與交付？

如果你覺得這太誇張了，那麼你認為什麼樣的頻率才是合適的？

從 CI/CD 的思維與觀念中，我們學習到任何的「變更」都有可能是造成異常的元兇。

控制變更的規模，不超越你團隊能承受的認知負擔，你才有辦法在發生問題時，快速定位出元兇身在何處。

你能夠快速説出上一次部署上線包含了多少變更？

以及這些變更分布在程式碼、Infra、Config、DB 或哪些位置？

假設讓你來掌控，你有把握絕不會搞砸正式環境的一次「發佈」，其「版本變更」的規模範圍會是多大呢？