Thoughts💡 Deploy on Fridays？關於週五部署這件事
筆者任職於 Yahoo ，粉絲團：《程式猿吃香蕉🍌》
這幾天軟體開發圈有個話題很熱：《 Deploy on Fridays 》，到底週五要不要部署呢？ 正方的論述，提到了 Allen Holub 的觀點：(參考來源)
‟Friday-deployment prohibitions tell me your quality control is so poor, your testing is so spotty, your process is so out of control, & your code is such a mess, that you see risk. It’s a huge red flag. Friday should be a day like any other.‟
『週五禁止部署的規定告訴我，你的品質控管太差了，你的測試參差不齊，你的流程非常失控，你的程式碼一團亂，因此你認為週五部署有風險，這是一個巨大的危險訊號，週五跟其他天應該是一樣的日子』
我覺得這個議題十分有趣，先說結論，我認同『週五跟其他天是一樣的日子』這個說法，但不同的地方在於，我認為禁止部署的舉措有其必要性，甚至我並『不』認為禁制部署是一個足夠完備的危險訊號。
由於缺乏背景情境 (Context) 的討論較容易失焦，因此，本文我將以開發團隊『能量水位』的概念來看這個問題，並輔以實際上會遇到的情境說明。
另外，我將週五禁止部署 (Friday-deployment prohibitions) 視為一種部署凍結 (Deployment Freeze) 的政策 (Policy) ，本文我也會分享目前在外商的工作經驗中，進行部署凍結的情境，供大家參考。
本篇文章包含
✔ 週五跟其他天應該是一樣的日子？談團隊能量水位
✔ 部署凍結 (Deployment Freeze) 是壞事嗎？
✔ 大公司也做部署凍結，為什麼？外商案例分享
✔ 結論：讓軟體更好的方向▍週五跟其他天應該是一樣的日子？
回答這個問題之前，我想要先談一個概念：『能量水位』(Capability)
我認為每個開發團隊都有所謂的『能量水位』(Capability)，我將它定義成能夠處理產品『問題』 (Issue) 與『風險』(Risk) 的能力。如下圖所示：當團隊的能量水位高的時候，可以完美處理產品出現的問題，此時軟體產品出包的風險較低，即使出現問題，團隊也能順利度過難關。
『能量水位』(Capability) 的高低也就會牽涉到團隊資源的問題，因此我認為：
一週間，每一天團隊的能量水位並不一致
就以『時間』這個維度來看，就有以下幾種情況，造成『能量水位』變動，舉例來說：
- 休假期間：可能因為團隊成員休假，導致能量水位暫時降低，不論是公司內或是公司外的夥伴休假，都有影響。
- 跨時區工作期間：與跨時區的同事做任務溝通時，當雙方時區的工作時間 (Wokring Hours) 重疊的時候，能量水位較高，因為系統有問題可以即時討論，但在不重疊的期間，溝通成本增高 (有重大事故需要叫對方起床處理)。
- 新成員加入期間：若是新人教育訓練沒做好，都有可能導致團隊能量水位降低。
- On Call 支援的期間：可能因為公司成本因素，無法提供足夠的 on call 支援，也會導致某些天的能量水位降低。
- 技術棧(Tech Stack)更迭期間：舉凡 Linux 、Java、PHP 或是其他軟體套件升級，亦或是從將服務改為 Dockerized 等等，由於新的技術棧在開發跟運維上都有學習曲線，這些都會造成團隊的能量水位降低。
每一天對開發團隊來說，都是『不一樣』的日子。
因此，回到最一開始的問題：『週五跟其他天應該是一樣的日子？』
我會說：『是』，因為：
週五跟其他天應該是『一樣』的日子，『一樣』很『不一樣』
▍部署凍結 (Deployment Freeze) 是壞事嗎？
既然週五跟其他天一樣地『不一樣』，那麼為什麼還需要部署凍結？如果我們團隊做了部署凍結，是不是顯得我們太糟了？
我相信多數的軟體開發者都期待自己的團隊天賦異稟、能力超群，能夠全天候 24 小時將團隊能量水位維持高檔，做到週五部署也不怕。
但現實上，以譬喻來說：
你可以一週每天早上6點都跑完 5000公尺嗎？
當然，這件事對於體能維持良好的人來說不是問題，但對於一般人來說，可能有困難，週六日需要休息一下來養足精神。
同樣地，不同的軟體開發團隊也一樣，有些公司家大業大，一秒鐘幾十萬上下，有能力和資源將團隊能量水位維持高檔，即使在週五下班前最後一個小時部署也不怕。然而，某些公司可能連 on call 的加班費都捉襟見肘。對於後者這類公司來說，也許他們團隊的程式碼寫得不差，但因為人事經費問題，週五部署的風險無法被處理，因此，週五的部署凍結對於他們來說就有其必要性。
以上的情況，如下圖所示，每天系統都有潛在的風險(見下圖週四的部分)，透過團隊的能量水位來處理(Cover)，在週五部署了新版程式之後，風險略為增高(見下圖週五的部分)，但週六跟週日沒有足夠的能量水位來處理風險。
因此，我認為部署凍結並無完全那麼糟糕，甚至連大公司也會進行部署凍結，下面我將分享我自己實際中遇到的幾個例子。
▍大公司也做部署凍結 (Deployment Freeze)？
若是有在美商待過的朋友，可能會知道『 Moratorium 』這個詞，這個詞中文不太好翻譯，但大致是指『暫停』的意思。在 Moratorium 期間，所有的部署都需要被限制，除非有非常、非常、非常重要的原因，否則在該期間，基本上是屬於部署凍結的狀態。
Moratorium 的期間是由公司認定的，公司認為在該期間部署風險過大，若系統出錯對於公司營收會有巨大影響，例如：
- 感恩節前夕
- Black Friday & Cyber Monday 前夕
- 聖誕節與新年前夕
- 總統大選前夕
以線上廣告業務來說，在這些重大日子，廣告主下的預算特別的多，在此期間，若是系統出問題，損失難以估量。雖然仍是同一個系統，但在重大日子當天，任何風險都會被放大，因此團隊在處理危機的時間上會更為緊迫，在壓力之下，團隊的判斷跟處置也有可能會被影響，屆時團隊的能量水位可能會不足以處理，因此在這些重大日子前夕，會做部署凍結的處置。
如下圖所示，每次部署雖然都略微注入風險，但在重大日子來臨，當天的風險都會被放大，可能會造成團隊的能量水位透支。
反之，如下圖，在重大日子前夕做部署凍結，來進行風險的控制，在重大日子當天，風險陡增時，團隊依然可以處理。
可能有些朋友會認為，那麼我們應該要去控制每次部署的風險，這樣即使我們在聖誕節前一天的最後一個小時部署，也可以不用怕了。是不是你們的程式碼品質太差，測試參差不齊，流程沒有管理好等等？
我認為這確實是值得努力的方向，但現實上很難。甚至我必須說，目前公司是我待過，程式碼品質最高，測試最完整，軟體工程走得最前面的地方。
對大公司來說，這些大型系統 End to End 的組成複雜，牽涉到多個團隊的協作，除了跨時區的團隊，有時候甚至是與外部夥伴 (Partner) 的系統串接，如果出了問題，嫌疑犯太多，在時間的壓力下並不容易直接追查出問題源頭。在成本的考量下，部署凍結也許是不得以而為之的作法。
即使公司在日常保有充沛的團隊能量水位：休假控管做得好、跨時區工作無縫接軌、新人交接做得棒、On call 秒接秒回、技術棧更迭下團隊專業罩得住。然而，在特定的日子，面對極大陡增的風險，也是有可能需要做部署凍結的。
▍結論
綜合以上觀點我認為：
- 週五跟其他天一樣，都是很不一樣的一天。
- 週五是否部署還需要看團隊每天的能量水位 (Capability)，而能量水位很難每天都相同的。
- 即使團隊的能量水位 (Capability) 都維持高檔，面對特定日子陡增的風險還是有可能會部署凍結。
- 大公司也做部署凍結的，有可能是系統 End to End 組成過於複雜，為了控管風險而為之。
最後，提升團隊能量水位，降低部署時所注入的風險，是讓我們軟體變得更好的方向，希望能做到 dpeloy on any day 甚至 any hour，每一天都視為相同的一天，每個小時視為相同的小時，那麼相同卻又不同。於異中求同，玩轉變化，這不正是我們工程師最擅長的超能力嗎？
以上一點心得分享，希望對大家有幫助。
若是喜歡我分享的內容，歡迎幫我按個拍手，可拍 50下，給我一點鼓勵，或是加入我的粉絲團《程式猿吃香蕉🍌》，一起分享軟體知識與心得！
