承担集团数万应用、研发人员日常工作，阿里持续交付平台的设计、迭代之道...
摘要： 阿里持續交付平臺已經經歷了 8 年的不斷迭代進化，成長為集團幾萬應用所依賴的最重要的研發工具，它的效率直接影響著幾萬研發日常工作。但平臺不能只是工具的堆砌，更需要針對互聯網時代的研發模式進行深度思考，不斷打磨，將工程師文化和工程師實踐不斷地融入其中。
阿里持續交付平臺已經經歷了 8 年的不斷迭代進化，成長為集團幾萬應用所依賴的最重要的研發工具，它的效率直接影響著幾萬研發日常工作。但平臺不能只是工具的堆砌，更需要針對互聯網時代的研發模式進行深度思考，不斷打磨，將工程師文化和工程師實踐不斷地融入其中。輕管控重技術，使用業界上最新工程實踐，用技術的演進去解決技術人的效率問題。本次演講將介紹阿里持續交付工具的演化歷程和對互聯網行業交付領域熱點問題的思考實踐。
注：本文整理自阿里巴巴高級技術專家陳鑫（神秀）在 ArchSummit 全球架構師峰會 2017 深圳站上的演講，原題為《互聯網時代的持續交付》。
寫在前面
大家好，我來自阿里巴巴，花名神秀，今天給大家帶來的 topic 是互聯網時代的持續交付。為什么在持續交付前面要強調互聯網？阿里的持續交付實踐有什么特別之處？希望我在這里能夠拋磚引玉，給大家帶來一點點收獲。
我在阿里負責持續交付平臺和研發工具鏈建設，以及將對應的能力通過阿里云輸出，我們對外的版本叫云效，公有云上目前正在公測中。
首先給大家介紹下今天的幾個主要內容。
首先著重介紹一下阿里這些年持續交付工具上的演進和我們的建設思路。
然后會和大家一起探討一下互聯網企業產品快速演進下的一個重要話題：質量和效率，介紹我們怎么看待這兩者之間的關系，以及如何協調。
再一個是我們正在面對的問題：交付和 devops，傳統軟件企業對交付肯定不陌生，但對于阿里場景下我們會有一些新的挑戰。Devops 方面介紹下我們最近一年的進展和一個小創新。
發展：持續交付在阿里
時間線
首先介紹下阿里持續交付平臺的發展歷程：第一階段2009 年我們做了一個簡單的自動化發布工具，來解決 SCM 和 PE 同學單點問題。在這之前可能很多企業都經歷過這樣的過程，固定時間提交發布申請，配管同學開始統一凍結代碼打包，然后交給運維同學進行發布。在小團隊小企業時也勉強夠用。應用規模越來越大，線上環境越來越復雜時，配管和運維同學的能力和效率開始阻礙我們產品的發展。當然其中也有一些腐敗，比如要搭車緊急發布要請配管同學喝咖啡什么的。開個玩笑。
沒過兩年，研發人員越來越多，各種復雜研發規范，線上各種復雜腳本，各種新同學挖坑，后人踩坑苦不堪言。這一切必須規范起來，后來到了 2013 年我們把從代碼變更到線上發布完全統一了起來，通過統一構建部署平臺進行嚴管控。
顯然這還遠遠不夠，到了 2016 年，平臺再度升級。上線了從需求到代碼，從交付到反饋的一站式平臺。項目、需求、代碼、構建、測試、發布、流水線、輿情反饋等等等等，產品大圖基本完備。
在 2017 年，我們把這 8 年的平臺工具經驗開放到了阿里云，也就是云效這個產品，希望通過阿里經驗反哺云上生態，同時也依托廣大研發者的經驗幫助我們工具成長。
工具與理念演進
說完了發展歷程，下面介紹下我們的工具和理念的演進過程，下面會針對這四點詳細展開。
第一是自動化，自動化是工具首先要完成的價值，也是效率提升的最直接的抓手。對于我們會先做好配置、代碼、測試、運維的自動化。
第二是標準化，標準化是工具平臺最大使命，比如亞馬遜經常講到的Apollo環境部署工具就做的非常棒，阿里也有自己的研發標準和運維標準，研發標準中比如研發模式、技術棧、配置管理規范相對好做。運維域就相當困難，目前 web 應用、移動應用、搜索、系統基礎軟件等會自成體系，集團內部和阿里云也會略有不同。但是隨著容器化和統一調度的推進，這些都有望統一。
第三是定制化，定制化應該是對平臺的更高要求，不同團隊，不同技能水平對工具天然就有不同的需求。我們不能因為管控而喪失靈活性，也不能因為照顧低水平技能而限制高水平。因此我們會首先按照團隊成熟度來推薦適合的交付過程和管理規范。
第四是一站式，當工具開始百花齊放時，對研發同學是有一定傷害的，不同的交互，不同的產品對接形態，不但會增加系統復雜度，也讓效率在平臺之間的流轉中降低。因此我們通過平臺工具融合，將需求到反饋的整條鏈路打通，在一個平臺完成基于價值的交付。
自動化一切
好，先看下我們的第一個理念：自動化一切。這張圖展示的是一個常見的研發過程，我們先從 master 拉出開發分支進行開發，合并成 release 分支進行發布，發布完成后合并到 master。應該每個研發團隊都有自己的一套規范來處理分支問題。當團隊規模越來越大，或者出現新人的時候，如何規范操作，提高協作效率，避免錯誤，那么就需要工具來承載這一切。
我們將常見的幾種研發模式：主干開發、分支開發、gitflow 等從拉分支開始，到 mergerequest、代碼合并、沖突解決全部白屏化解決，最終簡化成一個 pipeline，一個開發新手只需在平臺上操作就可以馬上融入研發工作而不會出現任何差錯。
標準化落地
再看關于標準化方面，工具層面主要完成了這幾個方面：應用創建、測試驗收、標準環境、上線卡點、部署過程。
一個應用對應一個代碼庫，一個服務單元，我們通過代碼推薦、技術棧模板對集團標準進行落地和迭代，比如 springboot 推廣。通過資源編排來快速完成基礎設施的申請搭建。
測試驗收方面集團規約和安全測試是這幾年主推的標準，已經在全集團落地，代碼質量得分則是通過數據度量的方式，客觀評測當前應用質量情況。
標準環境是交付流水線和運維管控的基礎，通過容器化和統一調度現在可以比較容易的實現，第四點比較有意思。原來的工具思路往往是出現部署、資源問題，會引導用戶通過自動化工具自助解決，比如清理日志、重啟機器等。現在我們會更多的采用自愈的方式，把環境資源運維工作下沉到平臺無人干預式解決，用工具替代人。
上線卡點多是一些管控類需求，基于集團統一的管控策略來定，控制研發行為和質量。
最后部署過程，發布策略、監控、基線、回滾都是必備功能，我這里就不再贅述了。
定制化解決方案
要實現定制化，先看下解決方案的幾個因素：
團隊成熟度：規模如何，1-2 人，7 人，10 人以上？全棧還是有獨立測試運維團隊？質量如何，是否有技術債務？團隊內部有什么特別的規范約定？
迭代速度：每日隨時發？還是周期性交付？是否有窗口限制，從我們持續交付的角度，我們并不想對上線行為做過多約束，符合卡點應該即可上線，阿里現在核心應用基本都做到隨時發布，甚至一日多次發布。
BU 技術棧：各自 BU 的一些私貨規范，和個性化差異。雖然我們一直在建設統一基礎設施和研發運維平臺，仍然無法做到 100% 統一，是我們一直努力的方向
最后是集成交付：是否有產品集成需求，項目交付？或者專有云交付。比較典型的就是電商、移動端、阿里云三種形態。
由這四點因素我們推導出了幾種定制化方向：
研發模式：根據應用小規模團隊采用分支研發，共建型大團隊采用 gitflow，更加龐大的團隊采用主干開發模式。因為微服務設計的流行，現在應用的團隊規模越來越小，所以在阿里分支研發模式會更受歡迎。
技術棧：java、C++、腳本類等等，我們會采用代碼推薦和模板化的方式，幫助用戶一鍵創建代碼框架和編譯環境。
部署模板：常見的做法是軟件包模板和 Dockerfile。在阿里，很多 BU 架構負責人和 PE 都會提供各種技術棧基礎鏡像，幫助普通研發者快速部署環境，類似這種的技術棧管控也同樣依靠工具來承載。
最后依靠多級 pipeline 來實現多種類型的交付過程，來滿足集成交付需求。
一站式平臺
大家現在看到的是目前阿里云效研發協同平臺的全貌，總體可以分為項目協作和持續交付兩大部分，交付部分形成了從需求到反饋的完整閉環，其中反饋部分不單單只有效能度量，還有針對業務本身的輿情分析和問卷調查，以及智能化客服工具。
工程師文化落地平臺
最后說一下我們建立平臺工具的最終目的，就是將工程師文化落地平臺。當然工程師文化是一個很虛的東西，每個企業都有自己的文化。包括阿里自己內部淘系、B2B、阿里云等 BU 都有各自特點。不過總結下來會有以下四點：
質量文化：質量是持續交付的核心所在，團隊成長的必經之路。沒有質量的文化傳承，效率無從談起，代碼會很快腐爛，無人敢動，成為技術債務。更不要說快速迭代和持續交付了。
創新文化：作為研發中臺的我們，不可能也不必要成為所有工具創新、效率創新的來源。在阿里本身也有濃厚的創新文化，今天我們碰撞出一個 idea，明天就有一幫哥們把他變為一個工具或者小產品。創新被人發現后還會快速的發展成一系列生態。這些事情每天都在發生，對于我們工具平臺來說，應該成為一個載體，將最優秀的創新落地在平臺之上，促進相似產品的融合避免重復造輪子，也可以推廣引流，做強做大，形成正向循環。
全棧文化：現在都在講 devops，但沒有工具承載的 devops 基本上是空談，當我們平臺可以幫助 dev 自動完成 ops 工作，或者引導促進知識學習時，才能做到研發、測試、運維協作的無死角。
精益文化：這個才是我們一站式平臺的理念所在：基于價值的交付，基于數據的準確度量，幫助開發或者領導者評估產品價值和優化團隊效率。
好，以上就是我們對阿里內部研發工具建設上的一些實踐，希望能夠拋磚引玉，共同探討。
兩大挑戰：質量和效率
接下來我們探討一個話題，質量與效率，這可能是工程領域一個永恒的話題，我們今天就聚焦在互聯網場景下，我們的軟件怎么來解決既要又要還要的問題。
先看下在互聯網時代我們的一些挑戰：
當交付速度決定市場：我們 CTO 曾說過，研發工具要保障一個 idea 從誕生到上線在 2 周內完成，快速試錯，不行就干掉，好了就拉一幫人做大做強。對于傳統研發方式來說，這似乎非常困難，但是卻真實發生了。
在這個前提下，我們的質量效率將如何選擇？
開著飛機換引擎會成為常態？基于我們前面的假設，先占領市場，再不斷迭代優化，基本已經成為我們軟件研發的共識。現在如果有人說，我們是開著飛機換飛機，我可能都只能“呵呵”一聲，因為我們自己就經常這么干，對吧。
持續集成面臨挑戰
再來看我們持續集成面臨的挑戰：
缺少測試覆蓋的持續集成成為負擔。當我們單測、API 測試做的不好的時候，通過流程強加的持續集成基本上是自欺欺人，要不就是不穩定，要不就是沒效果。
測試團隊轉型，開發全棧導致的質量下降。有這么多需求，沒時間寫測試，或者保姆式服務享受慣了，自己沒這個意識，等等等等。
測試環境互相依賴產生不穩定因素，在阿里集成環境問題應該是研發過程中的一大痛點。
看了這么多問題，我們需要思考，除了推動完善測試，我們還能做什么？
從工具要效率
好，我今天要講的是，從工具要效率，質量與效率并重。首先我們看下我們從哪里能獲得效率？
第一個快速反饋，我想對于效率我們首先能想到的詞是快，也就是快速反饋。加快構建速度，加快回歸速度。
第二個是協作，因為往往溝通成本是程序員的一大開銷，而且咱們還不太擅長，對吧，經常會發現 IQ 和 EQ 成反比。因此降低協作成本，可以有效提升效率，比如分支開發模式，在線審核，移動辦公等等
第三個是創新，原有粗放型，人力型無法延續的時候，創新可能是唯一出路。比如雙引擎測試、mock 測試等等。
以上三點我會一一舉例來介紹。
協作成本
先來看一個協作的例子，分支開發和主干開發這兩種研發模式的對比。
所謂分支開發，就是所有人都在分支上進行編碼，比如需求，bug 等等，需要集成時合并到一個臨時 release 分支上進行打包發布，發布完成后合并到主干。
所謂主干開發，即開發者直接在主干上進行編碼，開發完成后立即提交主干，發布時采用最新主干代碼進行打包發布。
好，接下來我們看下兩種研發模式的對比：
首先看是否建立分支的區別。分支開發模式每個 feature 都建立分支，利于管控，看到分支馬上明白是做什么事情。主干模式直接提交主干，通過 commit 來區分。
第二點，分支研發需要多次集成合并 release，必然會產生重復沖突，集成后測試會導致測試反饋滯后。而主干開發則只需解決一次沖突可以做到提交后即集成。
第三點，當某個分支功能不想發布了，分支模式可以直接退出集成，需要發布的分支重新合并 release 即可。而主干開發往往采用特性開關方式 off 掉相應功能，因為代碼剝離比較困難。
第四點，當線上某次發布被回滾掉了，分支模式我們可以把主干進行回滾，下次 release 分支合并時即可自動回滾，防止錯誤代碼被重復發上線。而主干模式需要進行 hotfix，在此之前可能會 block 后續發布。
通過以上四個場景的對比，我們把相對利于協作的標為黑色，不利于的標為白色。可以看出分支模式似乎略勝，尤其是在第三點，基于功能分支的任意集成給研發同學提供了很高的自由度。我們實踐下來，通過工具化支持，在微服務人員分工明確，耦合較少和快速迭代的場景下，大大減輕了分支開發集成反饋滯后的弊端。
快速反饋
好，我們看下一個效率點：快速反饋。研發過程中，隨著測試用例逐漸積累，測試時間也隨之增長，執行時間到 30 分鐘時我想應該都忍不了吧，幾杯咖啡都下肚了，測試還在跑好抓狂。這里我要介紹一個做的比較有意思的工具來達成快速的這個目標，我們叫他精準回歸。他有幾個特性：借助中間件全鏈路 trace 技術，建立測試用例與業務方法的關聯關系，當代碼變更時推薦需要執行的用例，精準回歸，快速反饋。
架構圖
來看下這張圖。首先我們通過 eagleeye，我們用于 tracing 的中間件插件，來對測試代碼和應用代碼進行打樁，注入 taceid。當測試用例執行時，我們記錄測試用例到應用代碼的完整鏈路日志，也就是 eagleeye log，通過日志采集送入實時計算引擎，計算出測試代碼和應用方法之間的關聯關系。
打個比方，當我們掌握了一個測試用例覆蓋了哪些應用代碼后，當代碼發生變化后，自然知道有哪些用例可以覆蓋到他，這樣只要執行這些用例就好了，幾十分鐘的測試時間縮短到幾分鐘甚至數秒，對于效率提升會非常巨大。
當然這個方案也不是一點瑕疵也沒有，在集成階段我們推薦運行完整用例集，不過這個沒關系，畢竟在開發階段測試運行的頻度要大于集成階段。
測試創新
先看三個問題：測試覆蓋不全怎么辦，寫測試用例尤其是好的用例需要大量時間。beta 測試會產生資損故障怎么處理，真實流量進入后，如果有 bug，肯定會導致一些問題，雖然影響小，但是也會導致一些不可彌補的問題。測試數據難以維護，經常被污染怎么辦，這是一個復雜而頭疼的問題。
為了解決以上問題，天貓業務團隊誕生了一個叫雙引擎測試的平臺，通過線上數據采集，線下服務隔離，執行重放和對比，自動完成回歸工作，輔助我們提高覆蓋率，大大提高效率。
架構圖
大家可以看這張架構圖，左邊是線上服務，首先通過 client 對線上請求進行采集，其中包括 request 和 response，以及下游系統，緩存、db 等等的調用鏈路快照。通過 mq 消息發送給 beta 環境的 client 進行回放。
這里就簡單進行回放請求就完成了么？顯然不是，該工具最核心的是對應用所有的下游依賴進行了隔離和 mock，比如應用發送給 db 一條 sql 查詢數據，雙引擎測試平臺會將這個請求阻斷，并返回線上同樣查詢的快照數據。最終拿到應用的 response 進行實時對比，存儲不一致結果。
通過這種機制，我們可以輕松實現線上請求，線下回放測試，debug，專注測試業務代碼本身，隔離依賴避免干擾。
在這個工具上面，我們還可以長出很多比如用例管理、失敗分析，離線回放等等產品，目前該平臺在阿里已經形成了自己的生態圈，落地核心應用，并且保障了多次核心代碼的重構升級工作。
交付挑戰與 DevOps 實踐
前面我們介紹了阿里持續交付過去的一些實踐，現在的質量與效率挑戰，下面我會講一下我們當前正在做的和正在探索的兩個方向，交付和 devops。
國際化和私有云的轉變
說到交付這個話題，傳統企業一定不陌生，而且可以說是絕對的專家。現在阿里這樣的互聯網公司面臨著新的交付問題。當我們要把電商體系附能給合資公司怎么辦，我們要把基礎設施和完整阿里技術體系輸出該怎么辦，當我們應用巨多，形成網狀依賴以后怎么辦？聽著就是一個很龐大的事情是不是？
目前我們的兩個交付變化，從統一交付變為分批交付，比如我們先輸出電商中臺，再輸出電商上層業務應用。從整體交付變為分塊交付，當全部輸出后，要進行版本迭代，如此大的應用規模無法在做整體交付，此時就需要進行分塊交付。而且這個塊可能每次都會存在差異。這無疑對工具帶來了新的挑戰。
交付效率挑戰
我們接著說效率，我這里列了三點：
快速搭建：我們需要低成本的一鍵創建環境，復現問題，或者創建交付版本的集成測試環境。
測試回歸：當環境中存在多個版本服務怎么搞，而且怎么做到足夠得快
鏈路管理：交付的過程能不能做成一鍵式，交付的版本能否可視可控，避免交付風險。
下面我們針對以上三點舉例說明。
交付過程探索
在這里我把交付過程寫到了這個 pipeline 里，依賴識別，對比回歸，快速搭建，精準回歸，一鍵交付。
首先看依賴識別，為什么要做依賴識別，剛才提到了，當我的應用數量非常大，并且網狀依賴非常復雜時，讓人來識別依賴關系已經不靠譜了。而且我要交付一個功能，如果牽一發動全身的讓所有關聯應用來次整體輸出，涉及的團隊太多基本也不可持續。因此一定要工具來完成自動的依賴識別。借助全鏈路調用數據完全可以做到這一點。
比如我修改了 A1 這個版本，通過鏈路數據結合交付端鏈路快照，發現必須順帶著交付 B1 和 C1 兩個版本，此時系統幫我圈定了一個交付集，后續的測試工作可以基于此來開展。
集成測試開始前，我們可以借助剛介紹的雙引擎測試平臺進行數據回放，對比測試，確認對交付端數據的影響。
集成測試
接下來我們將進入集成測試階段，首先是快速搭建，通過應用容器編排，基于中間件隔離，我們可以很輕松的將 A1、B1、C1 進行隔離，形成一個小的集成鏈路。通過精準回歸技術，對變更功能進行快速反饋。
一鍵交付
最后是一鍵交付，除了基本的版本管理能力以外，我還可以在集團環境直接管理交付端的環境，讓研發人員交付過程成本降到最低。同時在交付端，支持灰度發布能力，進一步減少交付風險。
最重要的還是有通暢的反饋渠道，依靠在前面介紹的平臺產品大圖上反饋模塊的豐富功能比如輿情、問答，我可以快速掌握交付端情況，采取必要措施。
好，以上就是我們針對目前新的交付問題的一些做法，歡迎各位與我深入探討。
DevOps 之路關鍵是工具
最后一個話題 devops，在這里我并不會詳細展開，只是講下我們這一年多來 devops 轉型的一些心得和一個小創新。
從 15 年開始提轉型，阿里集團去掉了大部分業務的 PE 團隊，交給開發，16 年我們建設統一調度平臺和落地 docker 容器技術，并完成了核心應用升級。17 年可能會是 devops 在阿里最輝煌的一年，今年我們會完成所有活躍應用的容器化和上下游完整工具鏈建設。
在這里我列了三點，首先對研發來說最基本的 ops 是什么，應用配置、環境、軟件基線，線上變更再加上流水線的管控。這是天天在用的。
這么復雜的一套在容器化之前我們做的并不好，當容器化開始落地后，我們的環境進一步標準化，實現了代碼驅動變更，管理工具大幅簡化。以前的基線工具，軟件包校驗工具，批量執行工具都不需要了。并且通過配套調度系統，將環境資源真正交到了研發同學手里。
運維系統開始化繁為簡，服務下沉，自助型操作轉為自愈型，并且開始嘗試智能化解決方案。比如大促彈性調度。
DevOps 在阿里
看起來很美好是吧，實際上呢？不可否認，Ops 對開發者是有相當大挑戰的，尤其是相關運維基礎知識的缺失，解決問題能力的缺失。簡單地將 Ops 交給 Dev 就是 DevOps 了么？顯然不是，這不但對開發是一種傷害，還是一種效率低下的做法，以前 1000 個人能做的事情，現在需要 10000 個人來完成。
因此我們不能讓 DevOps 成為負擔，DevOps 機器人在路上。
DevOps 機器人
Devops 機器人實際上是基于數據的主動服務機器人，來隨時幫助開發者補充知識，解決問題，并且我們有一個機制來確保知識獲取的自閉環。
首先數據來自哪里？常見的，構建錯誤，機器上錯誤日志，部署相關的，容器相關的等等。我們首先通過將這些收集起來，再配合用戶的行為，比如代碼變更 Diff，配置變更等等，保存在數據平臺中。
當我們有了數據以后，通過機器學習分析相關性配合人的積累，比如來自專家，工具運營，普通開發者的知識庫，形成規則。
當再次產生同樣問題時，系統會自動推薦相關解決方案，幫助開發者解決問題，同時收集反饋訓練模型。
通過我們的數據積累和問題廣場這樣的產品建設，形成問題出現 =》方案推送 =》用戶反饋 =》知識貢獻的閉環。目前通過我們簡單的積累就已經達到了 70% 以上的匹配率，未來通過閉環的知識訓練相信 devops 機器人會更加智能。
作者介紹
陳鑫（神秀），負責阿里云云效持續交付平臺和研發工具建設，致力于企業研發效率、產品質量、DevOps 方向研究和探索。在阿里 6 年帶領過大數據測試團隊、測試工具研發團隊、持續交付平臺團隊。對研發協同、測試、交付、運維領域都有很深的見解。
總結
以上是生活随笔為你收集整理的承担集团数万应用、研发人员日常工作，阿里持续交付平台的设计、迭代之道...的全部內容，希望文章能夠幫你解決所遇到的問題。
