10種避免大型部署的方法
本文最初發佈於goiabada部落格，經原作者授權由InfoQ中文站翻譯並分享。
理想中的部署是小型、精簡、易恢復、快速的，並且只能佔據資料庫較小的空間，甚至是零佔據。然而，不管我們怎麼努力，有時候都無法達到這些目標，你的部署最終是恰恰相反的，是大型、複雜、難恢復、痛苦且緩慢的，並且佔據了很大一部分資料庫空間。如果你要部署的是軟體的關鍵部分，那就更糟糕了。
但是實際上有更多方式，可以讓這些情況變得更糟。下面這些點，如果你遵守了，就能保證部署就像一場噩夢，帶來的後果會困擾你和你的同事好幾天。
1. 不制定計劃
計劃真是煩。它們要花時間和精力，也不給你的軟體新增新的功能。要計劃一次部署，需要考慮清楚部署的範圍，更重要的是，要考慮清楚不應該部署的部分（指的是雖然不應該部署，但可能會部署到的內容）。好的部署計劃需要簡單明瞭地列出每個步驟，然後儘量將可能發生的問題也列舉出來。制定部署計劃的目的是在開始之前儘可能多地覆蓋盲點。當然了，如果你的團隊裡有程式碼忍者、軟體大師，或其他什麼高階的人物，那你就不需要計劃了，儘管隨意發揮吧。
2. 不規劃停機
停機也好煩，通常在奇怪的時間發生，比如說深夜或一大早，在客戶睡著的時候發生（當然你也非常希望是這樣的）。為什麼要切斷公開訪問，將客戶重定位到完美的“計劃維護頁面”？在和現場客戶在對生產的交流中感到崩潰的時候，為什麼還要給你和團隊制定平緩、清晰的時間表呢？生產除錯是最棒的除錯！當你的團隊在嘗試修復上週五晚上已經修復過的bug時，給客戶提供不一致的產品狀況，把他們晾在一邊讓他們雲裡霧裡試試？
3. 摒棄 好的日誌系統
只有錯誤不斷的軟體才需要日誌，你的軟體並不需要。為什麼要花時間和金錢在登入即服務平臺上（LaaS）？就讓整個團隊ssh進入生產環境，觀察日誌尾部。或更好的選擇是用緩慢、不可靠、使用者介面混亂的LaaS，這樣在部署的時候所有人的工作都是在找bug。
4. 丟掉 錯誤跟蹤器
看一下上面的圖片，就像日誌一樣，錯誤跟蹤器也很煩。相信自己不會有任何錯誤發生的是吧！在你的手中，絕對不會發生迴歸。而且，在你已經有日誌的時候，誰還需要用強大、快速、可靠的錯誤跟蹤平臺來追蹤異常？你擁有足夠的能力，可以在任何異常出現的時候grep，妥妥搞定。
5. 拋棄 開發用伺服器
開發用伺服器是對資源的浪費，它浪費時間又浪費金錢。要一個完全接近生產伺服器的副本有什麼用？有了它和開發環境還有什麼區別？當然，容器化已經抽象出了其中許多區別，但你（最好）有和開發環境中不同的網路設定、第三方API和其他的東西，甚至是容器也好。所以我們要膽子大一些，實現從開發到生產的飛躍！
6. 別 檢查環境變數
你的專案大概有80個訪問令牌、API金鑰、資料庫證書以及快取儲存憑證，遍佈在6個左右的YAML上。它們超級容易跟蹤，超難弄亂你的生產、開發和開發用環境（希望有）。不要再三檢查部署中已經變更的變數，你能避免幾個小時的痛苦除錯。
7. 別 管 部署後的資料一致性
在前面的步驟中，我們已經知道了在部署中客戶依舊可以使用軟體，所以在保證資料不一致性的道路上我們已經走了一半了。請保證不要讓新的程式碼接觸到資料庫，特別是資料庫結構本身。如果有問題發生，只要回覆提交併回滾，這樣你就不用擔心不一致了。
8. 別為後面的回滾做準備
如果所有都失敗了，額等等，這不會發生！在部署的時候可能會出現一些問題，但在完成之後我們就不需要回滾了，是嗎？真的是嗎？在所有事搞定之後，你制定了一個計劃（其實你不需要制定計劃，還記得嗎？），按照計劃一步步執行，一切順利，你就不需要回滾。但假設在部署後幾小時（或幾天），你需要回到之前提交或標記或任何地方。新的資料可能需要你手動切換回之前軟體版本可控的內容。別想，別計劃，這不太可能發生。如果發生了，你需要一個夜深人靜的夜晚，埋頭苦幹才能完成。累感不愛。
9. 拒絕和 團隊高效地交流
現在你已經知道了，你要有可怕的日誌和錯誤跟蹤系統。雪上加霜的是不和同事進行快速、直接和清晰的交流。如果你的同事等待你的及時回覆，你長時間不理他一定會有很戲劇性的效果。含糊地交代你在做的事情。點了回滾按鈕，但不小心“忘記”告訴其他人。總而言之，越裝傻越好。
只要你好好遵守上面的所有點，你就可以造成“完美的風暴”，如果你不遵守它們，你和你的團隊就能更容易地完成任務。但即使你有很好的部署時間，有時候情況也會突變。永遠會有盲點存在，它們多半是不可預知的。這就是軟體開發會遇到的情況，從它我們可以得出獲得糟糕部署的第10點，也是最後一點：
10. 如果所有事情都失敗了，不要對你的同事有耐心，不要理解他們！
本文作者
ofollow,noindex" target="_blank"> Leonardo Brito 是Guava的Ruby開發人員。
檢視英文原文：10 ways not to do a big deploy
感謝張嬋對本文的審校。