如何打造7*24h持續交付通道?阿里高階技術專家的5點思考
我們對於研發效能的討論,本質上是提高整個技術生態中的協同效率。如果僅從研發角度出發,技術團隊要實現的終極目標是7*24小時的靈活釋出視窗,以及更快的業務迭代能力。
7*24小時釋出視窗的實現其實並不簡單,受限於很多因素。我簡單的進行了分解。
一、系統
先從最基礎的開始說,當一個創業團隊只有幾個人,一兩個系統的情況下,是可以不考慮研發效率這回事的。因為不存在系統間的依賴,系統內的依賴也完全在一個可控的範圍內,本地起一個 Tomcat 或 Apache 就能開發、除錯。另外再加上團隊成員之間的高頻交流,基本上可以實現隨時隨地,想發就發的要求。
當業務逐漸複雜,開發人數擴充套件到10幾人時。提效的第一步是理清系統內的依賴關係,並促進角色的專業化。這也是大家所熟知的MVC,通過對檢視、模型、控制器的分離,對系統內的邏輯進行分層。把複雜的程式碼邏輯下沉到Model層,而檢視層交由更專業的前端來負責。
當然,在系統內部仍然有一些擴充套件的空間,比如模組化,為不同的業務劃分bundle等。但仍然沒有突破本身的瓶頸,而且單一的系統也很難突破機器的特理特性。
二、架構
當技術團隊已經達到幾十上百人的規模,當業務已經無法通過單一的應用來進行水平擴充套件時。分散式的架構是解決問題的有效手段。在07年時,阿里集團就在推進SOA化,無論是淘寶還是支付寶,原來的單一應用不斷被拆分出來,也在此時,承載服務化中樞的訊息等中介軟體蓬勃發展。
這種方式,實現了系統之間的解藕,激活了技術人員的生產力,同時增大了系統的彈性,實現了服務能力的低成本水平擴充套件。但因為複雜的呼叫關係,對於某一個貫穿多個應用的專案來說,無疑增加了整合的成本和質量的風險。
同時,如果對應用規模不加以規劃和控制的話,會導致應用數的不斷擴張,從而影響到整體的開發維護成本。
三、配置管理
阿里在5到10年前,是有一個專門的崗位叫SCM的,負責技術團隊內的程式碼管理,配置項管理和應用部署。特別是在服務化初期,開發人員的coding生產力被極度釋放,應用數出現一個井噴,對配置管理的需求不斷增強,並最終促使了配置管理的變革(截止到目前,專職的SCM團隊被“消滅”了)。
在講配置管理前,先講講程式碼分支管理機制。這也是很多研發模式變革的起點。在此,我先表達自己的觀點:沒有對與錯(先進與落後)的程式碼分支管理機制,只有適不適合自己團隊當下以及未來發展的管理模式。
先從大的層面上來說,我們當前所討論的都是為了解決並行開發的問題,即有多個專案或團隊對於同一系列應用進行功能開發。如果僅僅是序列開發,是基本不用太考慮程式碼管理策略。
1、分支開發、主幹釋出。核心理念是使用固定的主幹作為整合分支。使用分支進行開發,在合併到主幹分支後生命週期終止。當然除此之外,還有緊急釋出分支等。
2、分支開發、分支釋出。釋出成功後執行寫基線操作,確保主幹的及時更新和穩定。同時分支釋出的方式不依賴於大整合,保持很強的靈活性。
體現在專案上的流程為:
3、其他模式:主幹開發、分支分佈等。由於我們並不常用,所以略過。
相關閱讀:在阿里,我們如何管理程式碼分支
平臺化的支援:早期配管的人肉化,也造成了程式碼整合和部署的效率很低。不同角色之間的協同靠人來完成。因此在那個背景下,還需要一個配套的PMO組織來保障。在這樣一個歷史背景下,Aone(對外叫雲效)也孕育而生,從平臺化的角度來解決研發過程的協同、構建、整合和測試幾個複雜的過程。
為了更清楚的瞭解那個時期的痛點,我找了2009年左右的Aone(雲效)的藍圖,可以管中窺豹(這個時期我並沒有親自經歷過,只是針對於當時的老人做了些訪談和收集了一些資料)。我猜想也正因為這條道路面向未來解決問題造就了現在的Aone平臺(雲效)。
四、測試
當一個技術團隊小,負責應用少以及業務的使用者群體少時,是完全可以不用測試的。只有當業務發展到一定階段,使用者對於質量的容忍程度越來越低時,才引入專業的測試角色。其次,在軟體離線交付階段,由於軟體的召回成本很高,所以對於測試是不遺餘力的,但隨著線上交付時代的深入,測試團隊是否能夠快速的實現軟體質量的評測反饋,成為一個非常關鍵的問題。而也決定著,在打通上述各個環節後,7*24小時軟體持續交付通道是否能夠真正實現。
在講之前,我們再回顧一下上個章節。Aone(雲效)平臺實現了開發程式碼、配置、應用部署的線上化,現在只剩下最後的一環——測試。從2010年以來,B2B的測試團隊就希望可以把分層自動化平臺跟Aone(雲效)研發協作平臺繫結在一起,通過系統呼叫的方式來實現一個測試的快速驗證機制,並最終實現迴歸測試過程中的無人值守。
這個意義非常重大。應用的服務化後,技術的風險實際上是收斂的,大家都可以面向服務來進行開發,實現高內聚、構耦合。並且應用的釋出也更加靈活了。但對於測試來說,卻是極大的挑戰:
1、測試的層次增加了。
2、測試的輪次變多了。每次整合,每次釋出就有可能是一次完整的測試迴歸。
就如Aone(雲效)的推進間接取替了SCM這個角色一樣。研發平臺的快速發展和業務7*24小時釋出的述求,也開始衝擊測試在程式碼整合後的快速反饋能力。這是一個挑戰,也是一個機會。否則,前期釋放出來的所有生產力,最後全都被卡在了測試這最後一個環節,而且沒有辦法拆解(每拆解出來一個,測試工作量就增加一倍)。只能通過不斷疊加整合的應用量來提高整合測試的效率。
經過1688測試團隊幾代同學的努力,現在我們在這個方面總算有了些成績。我們已經通過分層自動化體系實現了60%以上釋出測試的無人值守,並且全年攔截故障在數百個級別(含頁面、UI等)。
它的實現邏輯如下:
五、文化
至此,真正所謂的7*24小時業務的持續交付通道已經完全打造出來。
<Aone/雲效流程圖>
我們再回顧一下:
1、應用內的架構分層,前端、後端、測試各應其職,通過專業化的力量激發了一輪生產力。
2、服務化的架構,讓技術人員可以面向服務來進行業務的開發,實現了架構上的高內聚低耦合。進一步釋放大規模技術團隊的活力。
3、研發平臺的搭建,提供了持續交付管道,實現了開發、測試過程的快速、準確傳遞。
4、依託於研發平臺,實現了環境的自動化部署,應用監控,程式碼檢查。掃除了研發過程的基建設施。讓技術人員聚焦於程式碼的生產。
5、測試自動化驗證體系,減少系統整合風險,提高整合的頻率。最終實現了程式碼的快速上線。
作者簡介
施翔,畢業於南昌大學,現就職於阿里巴巴新零售技術事業群CBU技術部,擔任高階專家職務,負責質量技術、系統穩定性和DevOps團隊。過去曾就職於中興通訊、支付寶等公司,善於通過技術手段解決研發環節質量問題,在系統高可用、測試工具研發、研發效率提升等方面有著豐富的經驗。