「並沒有案例顯示，上版前的簽核真能夠減少什麼風險或是降低問題發生的機率。」——《Azure DevOps 顧問實戰》

有一間企業號稱擁有完善的變更管理流程，每一項新的變更，都需要經過工程師提出申請、主管簽核、資安審查、變更委員會開會同意、最後再等待統一變更實施日的來臨，終於新的變更上線啦！

這樣一趟流程走完，是否有助於降低風險，沒有人知道，但可以肯定的是，當上一項變更部署上線時，不知道有多少新的變更早已在後面排隊等待。

多一個關卡、多一份安全、多一份責任，聽起來合理，但實際上呢？

層層簽核會拖慢整體的交付速度，造成變更有可能逐漸累積，小變更累積成大變更，反而導致風險指數上升。

甚至當變更的規模過大或時間過於緊迫，使得簽核者經常無法在短時間內消化時，這份「把關」最終只會變成一種責任轉嫁的心理安慰劑。

而 DevOps 則告訴我們要從多層次來解決這個問題。

妥善控制每次變更的範圍、持續頻繁的整合與交付、並且明確區分哪些驗證交給自動化、哪些才真正需要人工介入。

這樣建立起來的流程，才是真正可以被信賴的驗證機制，而不是一份等人蓋章的申請書。

你們公司的軟體開發交付流程，花最多時間的地方，是在驗證品質，還是在等人簽名？

你覺得留下簽名的人，有確實發揮品質檢核的能力，或他只是一枚橡皮圖章呢？