阿裡妹導讀：研發效能分為兩塊，一是用技術的更新來提升效率；二是提高整個技術生态中的協同效率，激發技術活力。阿裡巴巴技術團隊在此基礎上要實作的終極目标是打造7*24小時靈活釋出的通道，以及提供更快的業務代碼疊代能力。今天，阿裡巴巴進階測試開發專家傲野為你帶來關于研發效能的一些思考，希望對你有啟發。
7*24小時釋出視窗的實作其實并不簡單，受限于很多因素。我簡單地進行了分解。
一、系統
先從最基礎的開始說，當一個創業團隊隻有幾個人，一兩個系統的情況下，是可以不考慮研發效率這回事的。因為不存在系統間的依賴，系統内的依賴也完全在一個可控的範圍内，本地起一個 Tomcat 或 Apache 就能開發、調試。另外再加上團隊成員之間的高頻交流，基本上可以實作随時随地，想發就發的要求。
當業務逐漸複雜，開發人數擴充到10幾個人時。提效的第一步是理清系統内的依賴關系，并促進角色的專業化。這也是大家所熟知的MVC，通過對視圖、模型、控制器的分離，對系統内的邏輯進行分層。把複雜的代碼邏輯下沉到Model層，而視圖層交由更專業的前端來負責。
當然，在系統内部仍然有一些擴充的空間，比如子產品化，為不同的業務劃分bundle等。但仍然沒有突破本身的瓶頸，而且單一的系統也很難突破機器的特性。
二、架構
當技術團隊已經達到幾十個上百人的規模，當業務已經無法通過單一的應用來進行水準擴充時。分布式的架構是解決問題的有效手段。在07年時，阿裡集團就在推進SOA化，無論是淘寶還是支付寶，原來的單一應用不斷被拆分出來，也在此時，承載服務化中樞的消息等中間件蓬勃發展。
這種方式實作了系統之間的解藕，激活了技術人員的生産力，同時增大了系統的彈性，實作了服務能力的低成本水準擴充。但因為複雜的調用關系，對于某一個貫穿多個應用的項目來說，無疑增加了內建的成本和品質的風險。
同時，如果對應用規模不加以規劃和控制的話，會導緻應用數的不斷擴張，進而影響到整體的開發維護成本。
三、配置管理
在5 - 10年前，阿裡是有一個專門的崗位叫SCM的，負責技術團隊内的代碼管理，配置項管理和應用部署。特别是在服務化初期，開發人員的coding生産力被極度釋放，應用數出現一個井噴，對配置管理的需求不斷增強，并最終促使了配置管理的變革。
在講配置管理前，先講講代碼分支管理機制。這也是很多研發模式變革的起點。在此，筆者先表達自己的觀點：沒有對與錯（先進與落後）的代碼分支管理機制，隻有适不适合自己團隊當下以及未來發展的管理模式。
先從大的層面上來說，我們目前所讨論的都是為了解決并行開發的問題，即有多個項目或團隊對于同一系列應用進行功能開發。如果僅僅是串行開發，是基本不用太考慮代碼管理政策。
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、測試自動化驗證體系，減少系統內建風險，提高內建的頻率。最終實作了代碼的快速上線。
原文釋出時間為：2019-05-15
本文作者： 施翔
本文來自雲栖社群合作夥伴“
阿裡技術”，了解相關資訊可以關注“
”。