0 別把問題想得太複雜
- 如果有灰度釋出的能力，最好白天釋出；
- 如果沒有灰度釋出，只能在半夜釋出。
即使有灰度釋出能力，也不要沾沾自喜，好好反思一下你們的灰度釋出是否真的經得起考驗，還是僅僅是裝裝樣子。
回滾方案最好在上級環境中使用生產資料演練，避免在0.1%的情況下需要回滾時，發現無法簡單地透過釋出上一版本服務來回滾，屆時會非常尷尬。
同時，服務型別也需要考慮，比如大型網路遊戲（如《王者榮耀》），都是在午夜時間停服維護，這其實說明了問題。
1 形式上，必須凌晨！
必須得在凌晨上線。程式設計師的工作有一個“原罪”，就是別人很難看出來你有多努力，尤其是管理層。如果你不上班搞凌晨釋出，管理層看不到你的努力，尤其是部門的整體表現。既然能選擇凌晨上線，那就凌晨上線！
如果有加班費或者調休補償，凌晨上線大家嗑著瓜子兒，吃著零食，公司提供的外賣和飲料，像開派對一樣，和樂融融地等待凌晨。如果有領導或者HR路過，大家一個個愁眉苦臉，盯著螢幕苦苦思索，心裡想，怎麼還不結束呢。
即使上線跟你沒關係，也要來，大家要在一起，部門派對。技術上早就不需要這麼幹了，但我們這裡就是喜歡看苦情戲，必須得凌晨，只是這種凌晨非彼凌晨，一起開party~
2 說點實際的
外企的釋出流程
對於外企來說，釋出流程相對規範：
-
專案規模小，客戶不多：
這種情況下，隨時可以上線，比如一些管理系統或新專案的上線。 -
專案規模大，使用者量大：
這種情況下，通常選擇訪問量較少的時間上線，一般是凌晨，有時甚至是週末的凌晨。
- 年底會確定下一年的上線日期（release day），每個上線日之間會間隔一個半月，這個週期相當於敏捷開發中的迭代週期。如果業務組有需要，可以透過流程，在規定的上線日之外進行釋出。
- 每年都有程式碼凍結期（code freeze period），通常是12月凍結一個月，因為聖誕假期維護人員放假，處理問題不方便，所以這個月不允許釋出。如果需要釋出，需要高階別領導批准。
- 釋出環境分為測試、整合測試和生產環境。測試環境每個組可以自由釋出，整合測試環境需要郵件通知支援組進行釋出，生產環境只能在釋出日釋出。釋出通常是一鍵部署（one click deployment），開發組提前在Jenkins或Udeploy等部署工具中寫好指令碼，經過支援組稽核後，由支援組在釋出日進行實際操作。
- 釋出日前一週的週五會封閉整合測試環境，各開發組應該提前一週將程式碼部署到整合測試環境並透過測試，確保釋出時風險最小。如果在釋出周內發現問題，需要重新部署測試，需要部門領導審批。
- 釋出日一般在美國時間週五下午9點（中國時間週六上午9點），各組提前填寫釋出申請報告，透過審批後通知支援組進行釋出。釋出完成後，各組需要在生產環境上確認，沒有問題則表示釋出成功。
小公司的釋出流程
一些小公司的釋出流程類似於上述流程，都是敏捷開發流程，釋出前在測試環境上測試程式碼，釋出前程式碼會封版，確保程式碼質量。
網際網路公司釋出流程
對於包含高併發元件（如Redis叢集、Kafka等）的網際網路公司，釋出過程更加複雜，不僅需要管理程式碼，還需要重啟中介軟體，或使用中介軟體清洗或匯入資料。如果能在面試中證明自己參與過釋出，並解決過釋出中的問題，那麼一定能有效證明自己的商業專案經驗。
結論
無論是大公司還是小公司，凌晨釋出都是為了確保使用者影響最小化，同時也是為了在特殊情況下能快速響應並回滾。理解並掌握髮布流程，能夠幫助開發人員更好地應對上線過程中的各種問題。
關注我，緊跟本系列專欄文章，咱們下篇再續！
作者簡介：魔都技術專家，多家大廠後端一線研發經驗，在分散式系統、和大資料系統等方面有多年的研究和實踐經驗，擁有從零到一的大資料平臺和基礎架構研發經驗，對分散式儲存、資料平臺架構、資料倉儲等領域都有豐富實踐經驗。
各大技術社群頭部專家博主。具有豐富的引領團隊經驗，深厚業務架構和解決方案的積累。
負責：
- 中央/分銷預訂系統效能最佳化
- 活動&優惠券等營銷中臺建設
- 交易平臺及資料中臺等架構和開發設計
- 車聯網核心平臺-物聯網連線平臺、大資料平臺架構設計及最佳化
目前主攻降低軟體複雜性設計、構建高可用系統方向。
參考：
- 程式設計嚴選網
本文由部落格一文多發平臺 OpenWrite 釋出！