這幾年工作的一大體會就是，釋出日益變成研發流程中重要的一環，甚至很多時候釋出比研發本身還要關鍵。（程式碼沒改幾行，但是釋出出錯，那就是一個嚴重的事故）。移動網際網路產品的Release本身也分為多個型別：1. 版本釋出（AppStore, 各大應用市場更新），2. 服務釋出 （也叫周長釋出，後臺服務做了升級，或者程式碼做了重構等等），3. 緊急釋出 （Bug Fix, 線上出了緊急的故障，需要發版本升級）本文想討論的，主要為1這種型別，接下來的內容也基於過去3年，我的團隊的一些經驗教訓總結而成。
什麼時候做Release Plan?
釋出計劃什麼時候做，一般是上線前1到2天做。太早和太晚都不合適，主要原因是，提前太久做，專案還在執行中，很多細節根本定不下來，那時候做出來的計劃基本上是不靠譜的。第二，那時候攻城獅們都在忙著幹活呢，沒有心思討論具體的細節。釋出當天做，更不行，釋出當天，一堆事情需要梳理， 那時候再來動筆，如果中途出現任何么蛾子，效果可想而知。
Release Plan 包含哪一些內容？
一份釋出計劃，可以根據每次釋出的內容來做適當的調整，所以不可能有萬能的模板適合各種釋出，但是以下幾點，是建議要包括的：
1. 本次釋出的參與人
2. 釋出的範圍
3. 是否有相關依賴 （資料庫schema更改，index update, 某些服務需要reloading, blabla..）
4. 釋出的時間和順序
5. 釋出後的驗證方案
6. 如果有不能解決的異常，回滾方案
對於以上幾點，再做一下簡單的說明, 第一點，其實是最重要的，每次釋出，參與的人必須要明確，特別是釋出前的準備會，所有相關同學必須要在場，大家要對整個流程達到高度的認知一致。另外，請注意，這裡說的並不只是開發，測試，運維和產品這些常規角色，運營，法務，市場等角色也不能遺漏，上線後的驗收是需要業務部門參與的。
第二點，不用多說，釋出的範圍必須要明確，本次釋出，哪一些模組/功能需要上線。
第三點，現在的系統架構，包含了大量的中介軟體，一個功能的改動，很多時候不只是提現在程式碼的改動上，資料庫，配置檔案，快取更新等等，對新功能都會有影響。如果程式碼更新上去了，發現表結構還是上一個版本，那就等P1事故吧。
第四點，釋出日什麼時候開始啟動釋出流程？上班後9點開始？下班後7點開始，還是凌點？各個模組的釋出順序一定要明確，畢竟很多時候，都是非停機發布。
第五點，新版本釋出後那一刻，必須要有明確的驗證方案，包含驗證人，TestCase等，如果不能直接驗證，那麼更要提前造好對應的context以備做到第一時間進行確認。
第六點，我們任何時刻，都要做好最壞的打算，那就是釋出失敗，保持現有版本。
如何開好Release Plan的會議
釋出計劃的執行前，建議開一個釋出會議，用來全員同步和確認釋出計劃。釋出計劃會議的主持人是本次專案的負責人或者專案經理。會議過程中，逐條過每一個要點，每一個要點過完後，明確責任人或者介面人。會議結束後，將釋出計劃達成的結果發給所有與會人。
Release Plan執行過程中的要點
1. 時刻做好Tracking和Monitor, 每做好一個點，打一個勾；如果出現異常情況，立刻Raise一個Yellow Flag乃至Red Flag.
2. 做好異常情況的應對，比方說，IDC機房或者第三方雲主機出現故障，需要提前打好招呼，找到對應的介面人，而不是出事了，再來找人。
3. 釋出前，要提前和業務方打好招呼，告知對應的釋出計劃，保證不會業務釋出不會相互影響。
掃描二維碼或手動搜尋微信公眾號： ForestNotes
歡迎轉載，帶上以下二維碼即可