家裡有了小魚魚的這一個多月，真的是非常難忘的人生體驗... 陪產假結束重新投入工作，我們繼續對Release Manager的思考~

參見之前的總結和認識，Release Manager即是以“精益”為目標，踐行“持續交付”，實現更好的軟體交付質量和客戶滿意度。

首先在踐行“持續交付”時，不免要涉及多個領域團隊，此時要運用敏捷&Devops的理念將需求、開發、測試、運維等團隊融合為一體，打破以前各團隊各掃門前雪的孤立局面，讓每個團隊從需求階段就提前介入，持續關注交付過程並對交付質量全程負責。

搭建好團隊基礎後，就可以逐步建立持續交付的承載實體：流水線，讓交付過程變得“流動”和“視覺化”。此時持續交付不再是需要N多人評審和爭論的流程文件，而是清晰高效的系統工具。除了流動之外，還需要有全面的遙測監控體系和持續改進方法，來分析流動過程中哪些環節是可以提升的，讓流動性變得越來越好。

在Release Manager各階段的工作中需要運用到包括需求管理、變更管理、版本控制、持續整合、自動化測試、環境管理、持續部署、資料監控等多種軟體工程的流程方法論和工具手段。其中位於最前端也是最重要的即是需求管理，建立和維護清晰合理的特性-需求結構關係能夠幫助後續的研發過程有序可追溯，並且能有效幫助開發、測試、運維領域統一目標深入融合；變更管理和版本控制則是研發管理的基礎手段，所有的程式碼、指令碼、用例、環境配置、部署方案等均應該納入版本控制範圍，並通過變更管理與相對應的特性-需求一一對應起來，實現從前到後清晰的生命線；持續整合和自動化測試屬於研發管理的常用手段，能夠有效保障軟體的日常質量水平；環境管理和持續部署對於那些涉及大規模伺服器叢集進行高頻率部署&回滾的業務場景特別有效，但即使對於部署頻率較低的業務場景也應如此；資料監控則是涵蓋了研發的各個層面：應用程式效能、部署方案可行性、基礎設施穩定性等等。

最後，開展整個持續交付工作的前提，是要清晰理解IT軟體的商業目標，明確自身的釋出策略，確保我們所做的工作在商業導向和技術導向是一致的。因為IT軟體千千萬種，不同行業不同型別的IT軟體有自己的目標客戶，也有自己的商業模式，更有自身的釋出模式限制，不能一概而論。可以嘗試根據軟體部署到使用者感知的代價大小簡單劃分一下， 舉個例子：

服務主機端應用軟體比如入口網站、線上管理系統等，使用者直接通過網路流量來獲取其最新的功能和資訊，這種軟體的商業目標要滿足海量使用者不間斷的訪問體驗，而且使用者感知到軟體部署的代價非常小几乎為零，因此其釋出模式通常要求部署頻率比較高，能迅速解決使用者的問題。相對應地其持續交付工作重點在於環境叢集管理、持續部署和資料監控等，能夠確保部署的及時性和可回滾；

客戶PC端應用軟體比如IDE等，使用者通過一次性下載安裝包安裝來獲取其相應功能，這種軟體從部署到讓使用者感知的代價非常大，因此它的持續交付重點在於通過合理的架構設計實現部分功能支援線上更新從而能進行小規模持續部署等；

移動端應用軟體比如晶片軟體、手機軟體等，通常會通過特殊機制（OTA等）來進行持續部署，並通過重啟來完成使用者感知，這類業務的環境配置通常難以大規模重現，因此其持續交付工作重點在於環境管理和OTA升級機制管理等。

另外在搭建持續交付流水線時，可以考慮自己組合各類開源工具或者直接購買成熟的解決方案，當前比較火熱的持續交付流水線解決方案包括AWS的Code Pipeline、Azure的、Aliyun的等。後面我們會單獨對這些解決方案進行分析。

總結一下，Release Manager既需要開闊的眼界和對整體策略的把控，也需要對業務場景和工具技術的掌握，更要面對不同團隊的管理協調，故而“任重而道遠”。