「不常變動的 能早做就早做；常變動的 能晚做就晚做」——《30天與Docker做好朋友：跟鯨魚先生一同探索開發者的大平台》

今天的金句乍看之下像是一句廢話，但仔細想想，它其實滿有道理的，而且能適用在 DevOps 工程實踐的多個場景。

例如：我們在 Build container image 時，是不是會將安裝相依套件的步驟，盡量往前面放？而程式碼或有可能覆蓋的變數則盡量往後擺？

例如：CI/CD Pipeline 規劃，是不是會將越是穩定、固定、一定要做的 Job 往前擺，越是需要頻繁變更的驗證步驟往後移？

例如：Infrastructure as code 的設計，也會區分不常與經常變動的部分，把經常變動的抽離成參數，留到最後才注入？

在這些情境中，我們其實有著相同的原則，那就是「減少不必要的變更」，讓每一項變動只會影響到必要之處。

這項原則可以幫助我們減少重複的步驟、縮限變更的影響範圍、甚至還能適度的加速 DevOps Pipeline。

你們在規劃 DevOps Pipeline 時，還會遵守哪些原則？有沒有認真想過該如何安排 Job 的先後順序呢？