如何打造7*24h持續交付通道？阿里高級技術專家的5點思考

雲效鼓勵師導讀：打造7*24小時的持續交付通道是不少技術團隊求之不得的事情，那麼如何才能實現呢？阿里高級技術專家施翔帶來了他的思考。

此外，文末咱們還爲你們首次推出了阿里敏捷教練團隊傾心打造的提高研發效能36計課程之「看板+站會」相關內容課程，歡迎報名。

咱們對於研發效能的討論，本質上是提升整個技術生態中的協同效率。若是僅從研發角度出發，技術團隊要實現的終極目標是7*24小時的靈活發佈窗口，以及更快的業務迭代能力。

7*24小時發佈窗口的實現其實並不簡單，受限於不少因素。我簡單的進行了分解。

1、系統

先從最基礎的開始說，當一個創業團隊只有幾我的，一兩個系統的狀況下，是能夠不考慮研發效率這回事的。由於不存在系統間的依賴，系統內的依賴也徹底在一個可控的範圍內，本地起一個 Tomcat 或 Apache 就能開發、調試。另外再加上團隊成員之間的高頻交流，基本上能夠實現隨時隨地，想發就發的要求。

當業務逐漸複雜，開發人數擴展到10幾人時。提效的第一步是理清系統內的依賴關係，並促進角色的專業化。這也是你們所熟知的MVC，經過對視圖、模型、控制器的分離，對系統內的邏輯進行分層。把複雜的代碼邏輯下沉到Model層，而視圖層交由更專業的前端來負責。

固然，在系統內部仍然有一些擴展的空間，好比模塊化，爲不一樣的業務劃分bundle等。但仍然沒有突破自己的瓶頸，並且單一的系統也很難突破機器的特理特性。

2、架構

當技術團隊已經達到幾十上百人的規模，當業務已經沒法經過單一的應用來進行水平擴展時。分佈式的架構是解決問題的有效手段。在07年時，阿里集團就在推動SOA化，不管是淘寶仍是支付寶，原來的單一應用不斷被拆分出來，也在此時，承載服務化中樞的消息等中間件蓬勃發展。

這種方式，實現了系統之間的解藕，激活了技術人員的生產力，同時增大了系統的彈性，實現了服務能力的低成本水平擴展。但由於複雜的調用關係，對於某一個貫穿多個應用的項目來講，無疑增長了集成的成本和質量的風險。

同時，若是對應用規模不加以規劃和控制的話，會致使應用數的不斷擴張，從而影響到總體的開發維護成本。

3、配置管理

阿里在5到10年前，是有一個專門的崗位叫SCM的，負責技術團隊內的代碼管理，配置項管理和應用部署。特別是在服務化初期，開發人員的coding生產力被極度釋放，應用數出現一個井噴，對配置管理的需求不斷加強，並最終促使了配置管理的變革（截止到目前，專職的SCM團隊被「消滅」了）。

在講配置管理前，先講講代碼分支管理機制。這也是不少研發模式變革的起點。在此，我先表達本身的觀點：沒有對與錯（先進與落後）的代碼分支管理機制，只有適不適合本身團隊當下以及將來發展的管理模式。

先從大的層面上來講，咱們當前所討論的都是爲了解決並行開發的問題，即有多個項目或團隊對於同一系列應用進行功能開發。若是僅僅是串行開發，是基本不用太考慮代碼管理策略。

一、分支開發、主幹發佈。核心理念是使用固定的主幹做爲集成分支。使用分支進行開發，在合併到主幹分支後生命週期終止。固然除此以外，還有緊急發佈分支等。

二、分支開發、分支發佈。發佈成功後執行寫基線操做，確保主幹的及時更新和穩定。同時分支發佈的方式不依賴於大集成，保持很強的靈活性。

體如今項目上的流程爲：

三、其餘模式：主幹開發、分支分佈等。因爲咱們並不經常使用，因此略過。

相關閱讀：在阿里，咱們如何管理代碼分支

平臺化的支持：早期配管的人肉化，也形成了代碼集成和部署的效率很低。不一樣角色之間的協同靠人來完成。所以在那個背景下，還須要一個配套的PMO組織來保障。在這樣一個歷史背景下，Aone（對外叫雲效）也孕育而生，從平臺化的角度來解決研發過程的協同、構建、集成和測試幾個複雜的過程。

爲了更清楚的瞭解那個時期的痛點，我找了2009年左右的Aone（雲效）的藍圖，能夠管中窺豹（這個時期我並無親自經歷過，只是針對於當時的老人作了些訪談和收集了一些資料）。我猜測也正由於這條道路面向將來解決問題造就瞭如今的Aone平臺（雲效）。

4、測試

當一個技術團隊小，負責應用少以及業務的用戶羣體少時，是徹底能夠不用測試的。只有當業務發展到必定階段，用戶對於質量的容忍程度愈來愈低時，才引入專業的測試角色。其次，在軟件離線交付階段，因爲軟件的召回成本很高，因此對於測試是竭盡全力的，但隨着在線交付時代的深刻，測試團隊是否可以快速的實現軟件質量的評測反饋，成爲一個很是關鍵的問題。而也決定着，在打通上述各個環節後，7*24小時軟件持續交付通道是否可以真正實現。

在講以前，咱們再回顧一下上個章節。Aone（雲效）平臺實現了開發代碼、配置、應用部署的在線化，如今只剩下最後的一環——測試。從2010年以來，B2B的測試團隊就但願能夠把分層自動化平臺跟Aone（雲效）研發協做平臺綁定在一塊兒，經過系統調用的方式來實現一個測試的快速驗證機制，並最終實現迴歸測試過程當中的無人值守。

這個意義很是重大。應用的服務化後，技術的風險其實是收斂的，你們均可以面向服務來進行開發，實現高內聚、構耦合。而且應用的發佈也更加靈活了。但對於測試來講，倒是極大的挑戰：

一、測試的層次增長了。

二、測試的輪次變多了。每次集成，每次發佈就有多是一次完整的測試迴歸。

就如Aone（雲效）的推動間接取替了SCM這個角色同樣。研發平臺的快速發展和業務7*24小時發佈的述求，也開始衝擊測試在代碼集成後的快速反饋能力。這是一個挑戰，也是一個機會。不然，前期釋放出來的全部生產力，最後全都被卡在了測試這最後一個環節，並且沒有辦法拆解（每拆解出來一個，測試工做量就增長一倍）。只能經過不斷疊加集成的應用量來提升集成測試的效率。

通過1688測試團隊幾代同窗的努力，如今咱們在這個方面總算有了些成績。咱們已經經過分層自動化體系實現了60%以上發佈測試的無人值守，而且整年攔截故障在數百個級別（含頁面、UI等）。

它的實現邏輯以下:

5、文化

至此，真正所謂的7*24小時業務的持續交付通道已經徹底打造出來。

<Aone/雲效流程圖>

咱們再回顧一下：

一、應用內的架構分層，前端、後端、測試各應其職，經過專業化的力量激發了一輪生產力。

二、服務化的架構，讓技術人員能夠面向服務來進行業務的開發，實現了架構上的高內聚低耦合。進一步釋放大規模技術團隊的活力。

三、研發平臺的搭建，提供了持續交付管道，實現了開發、測試過程的快速、準確傳遞。

四、依託於研發平臺，實現了環境的自動化部署，應用監控，代碼檢查。掃除了研發過程的基建設施。讓技術人員聚焦於代碼的生產。

五、測試自動化驗證體系，減小系統集成風險，提升集成的頻率。最終實現了代碼的快速上線。

做者簡介

施翔，畢業於南昌大學，現就任於阿里巴巴新零售技術事業羣CBU技術部，擔任高級專家職務，負責質量技術、系統穩定性和DevOps團隊。過去曾就任於中興通信、支付寶等公司，善於經過技術手段解決研發環節質量問題，在系統高可用、測試工具研發、研發效率提高等方面有着豐富的經驗。