「部署管道正確的範圍始終是軟體可獨立部署的單元。」——《軟體架構指標：改善架構品質的案例研究》

應該要一起部署的「多項變更」，你是放在同一條 Pipeline 中，還是需要多個不同的 Pipeline 一起執行？

或者你有聽過另一種鬼故事叫做「分散式單體」（Distributed Monolith）？

多個 Dockerfile 對應多個儲存庫，再對應多個微服務，最後構成一個完整的系統。

多個微服務全部綁在同一個 Pipeline 中，一起 Build、Test、Deploy。

嗯，聰明的你，應該已經聞到某種壞味道了吧？（咦）

不過對於 Pipeline 的建置演進來說，這似乎不難理解，畢竟我們總是一路慢慢的建構與完善我們的 Pipeline，今天加上一個 Job、明天多一個服務整合，可能後天還要應付忽然增加的 Config 或客製化腳本。

一個不小心 Pipeline 就犯了那些軟體工程都會犯的錯誤，過度肥大、相依、耦合、難測試、難重構。

也難怪我們總是想要找一個更好的 CI/CD 工具。

也難怪 Pipeline 會發展成 Pipeline as Code，因為它本身就是一種程式碼，也需要被好好的管理。

回到今天的金句，在規劃交付及部署管道時，絕對要把握住「正確的範圍」，讓「交付」可以是一個剛好能自己上線，不用等待別人的單元。

這麼做不只是在解決你 Pipeline 複雜化的議題，它同時也是要求你在系統及架構設計時，就要關注剛剛好的系統邊界。

從設計就開始做起，才不會落到最後從程式碼、系統、甚至到你的 Pipeline 全都是難以處理的燙手山芋。