承擔集團數萬應用、研發人員平常工做，阿里持續交付平臺的設計、迭代之道

寫在前面

你們好，我來自阿里巴巴花名神秀，今天給你們帶來的 topic 是互聯網時代的持續交付。爲何在持續交付前面要強調互聯網？阿里的持續交付實踐有什麼特別之處？但願我在這裏可以拋磚引玉，給你們帶來一點點收穫。

我在阿里負責持續交付平臺和研發工具鏈建設，以及將對應的能力經過阿里雲輸出，咱們對外的版本叫雲效，公有云上目前正在公測中。

ok，讓咱們進入主題，首先給你們介紹下今天的幾個主要內容。

• 首先着重介紹一下阿里這些年持續交付工具上的演進和咱們的建設思路。

• 而後會和你們一塊兒探討一下互聯網企業產品快速演進下的一個重要話題：質量和效率，介紹咱們怎麼看待這二者之間的關係，以及如何協調。

• 再一個是咱們正在面對的問題：交付和 devops，傳統軟件企業對交付確定不陌生，但對於阿里場景下咱們會有一些新的挑戰。Devops 方面介紹下咱們最近一年的進展和一個小創新。

發展：持續交付在阿里時間線

首先介紹下阿里持續交付平臺的發展歷程：第一階段 2009 年咱們作了一個簡單地自動化發佈工具，來解決 SCM 和 PE 同窗單點問題。在這以前可能不少企業都經歷過這樣的過程，固定時間提交發布申請，配管同窗開始統一凍結代碼打包，而後交給運維同窗進行發佈。在小團隊小企業時也勉強夠用。應用規模愈來愈大，線上環境愈來愈複雜時，配管和運維同窗的能力和效率開始阻礙咱們產品的發展。固然其中也有一些腐敗，好比要搭車緊急發佈要請配管同窗喝咖啡什麼的。開個玩笑。

沒過兩年，研發人員愈來愈多，各類複雜研發規範，線上各類複雜腳本，各類新同窗挖坑，後人踩坑苦不堪言。這一切必須規範起來，後來到了 2013 年咱們把從代碼變動到線上發佈徹底統一了起來，經過統一構建部署平臺進行嚴管控。

顯然這還遠遠不夠，到了 2016 年，平臺再度升級。上線了從需求到代碼，從交付到反饋的一站式平臺。項目、需求、代碼、構建、測試、發佈、流水線、輿情反饋等等等等，產品大圖基本完備。

在 2017 年，咱們把這 8 年的平臺工具經驗開放到了阿里雲，也就是雲效這個產品，但願經過阿里經驗反哺雲上生態，同時也依託廣大研發者的經驗幫助咱們工具成長。

工具與理念演進

說完了發展歷程，下面介紹下咱們的工具和理念的演進過程，下面會針對這四點詳細展開。

第一是自動化，自動化是工具首先要完成的價值，也是效率提高的最直接的抓手。對於咱們會先作好配置、代碼、測試、運維的自動化

第二是標準化，標準化是工具平臺最大使命，好比亞馬遜常常講到的 Apollo 環境部署工具就作的很是棒，阿里也有本身的研發標準和運維標準，研發標準中好比研發模式、技術棧、配置管理規範相對好作。運維域就至關困難，目前 web 應用、移動應用、搜索、系統基礎軟件等會自成體系，集團內部和阿里雲也會略有不一樣。可是隨着容器化和統一調度的推動，這些都有望統一。

第三是定製化，定製化應該是對平臺的更高要求，不一樣團隊，不一樣技能水平對工具自然就有不一樣的需求。咱們不能由於管控而喪失靈活性，也不能由於照顧低水平技能而限制高水平。所以咱們會首先按照團隊成熟度來推薦適合的交付過程和管理規範。

第四是一站式，當工具開始百花齊放時，對研發同窗是有必定傷害的，不一樣的交互，不一樣的產品對接形態，不但會增長系統複雜度，也讓效率在平臺之間的流轉中下降。所以咱們經過平臺工具融合，將需求到反饋的整條鏈路打通，在一個平臺完成基於價值的交付。

 自動化一切

好，先看下咱們的第一個理念：自動化一切。這張圖展現的是一個常見的研發過程，咱們先從 master 拉出開發分支進行開發，合併成 release 分支進行發佈，發佈完成後合併到 master。應該每一個研發團隊都有本身的一套規範來處理分支問題。當團隊規模愈來愈大，或者出現新人的時候，如何規範操做，提升協做效率，避免錯誤，那麼就須要工具來承載這一切。

咱們將常見的幾種研發模式：主幹開發、分支開發、gitflow 等從拉分支開始，到 mergerequest、代碼合併、衝突解決所有白屏化解決，最終簡化成一個 pipeline，一個開發新手只需在平臺上操做就能夠立刻融入研發工做而不會出現任何差錯。

 標準化落地

再看關於標準化方面，工具層面主要完成了這幾個方面：應用建立、測試驗收、標準環境、上線卡點、部署過程。

一個應用對應一個代碼庫，一個服務單元，咱們經過代碼推薦、技術棧模板對集團標準進行落地和迭代，好比 springboot 推廣。經過資源編排來快速完成基礎設施的申請搭建。

測試驗收方面集團規約和安全測試是這幾年主推的標準，已經在全集團落地，代碼質量得分則是經過數據度量的方式，客觀評測當前應用質量狀況。

標準環境是交付流水線和運維管控的基礎，經過容器化和統一調度如今能夠比較容易的實現，第四點比較有意思。原來的工具思路每每是出現部署、資源問題會引導用戶經過自動化工具自助解決，好比清理日誌、重啓機器等。如今咱們會更多的採用自愈的方式，把環境資源運維工做下沉到平臺無人干預式解決，用工具替代人。

上線卡點可能是一些管控類需求，基於集團統一的管控策略來定，控制研發行爲和質量。

最後部署過程，發佈策略、監控、基線、回滾都是必備功能，我這裏就再也不贅述了。

 定製化解決方案

要實現定製化，先看下解決方案的幾個因素：

1. 團隊成熟度：規模如何，1-2 人，7 人，10 人以上？全棧仍是有獨立測試運維團隊？質量如何，是否有技術債務？團隊內部有什麼特別的規範約定？

2. 迭代速度：每日隨時發？仍是週期性交付？是否有窗口限制，從咱們持續交付的角度，咱們並不想對上線行爲作過多約束，符合卡點應該便可上線，阿里如今核心應用基本都作到隨時發佈，甚至一日屢次發佈。

3. BU 技術棧：各自 BU 的一些私貨規範，和個性化差別。雖然咱們一直在建設統一基礎設施和研發運維平臺，仍然沒法作到 100% 統一，是咱們一直努力的方向

4. 最後是集成交付：是否有產品集成需求，項目交付？或者專有云交付。比較典型的就是電商、移動端、阿里雲三種形態。

由這四點因素咱們推導出了幾種定製化方向：

1. 研發模式：根據應用小規模團隊採用分支研發，共建型大團隊採用 gitflow，更加龐大的團隊採用主幹開發模式。由於微服務設計的流行，如今應用的團隊規模愈來愈小，因此在阿里分支研發模式會更受歡迎。

2. 技術棧：java、C++、腳本類等等，咱們會採用代碼推薦和模板化的方式，幫助用戶一鍵建立代碼框架和編譯環境。

3. 部署模板：常見的作法是軟件包模板和 Dockerfile。在阿里，不少 BU 架構負責人和 PE 都會提供各類技術棧基礎鏡像，幫助普通研發者快速部署環境，相似這種的技術棧管控也一樣依靠工具來承載。

4. 最後依靠多級 pipeline 來實現多種類型的交付過程，來知足集成交付需求。

 一站式平臺

你們如今看到的是目前阿里雲效研發協同平臺的全貌，整體能夠分爲項目協做和持續交付兩大部分，交付部分造成了從需求到反饋的完整閉環，其中反饋部分不僅僅只有效能度量，還有針對業務自己的輿情分析和問卷調查，以及智能化客服工具。

工程師文化落地平臺

最後說一下咱們創建平臺工具的最終目的，就是將工程師文化落地平臺。固然工程師文化是一個很虛的東西，每一個企業都有本身的文化。包括阿里本身內部淘系、B2B、阿里雲等 BU 都有各自特色。不過總結下來會有如下四點：

• 質量文化：質量是持續交付的核心所在，團隊成長的必經之路。沒有質量的文化傳承，效率無從談起，代碼會很快腐爛，無人敢動，成爲技術債務。更不要說快速迭代和持續交付了。

• 創新文化：做爲研發中臺的咱們，不可能也沒必要要成爲全部工具創新、效率創新的來源。在阿里自己也有濃厚的創新文化，今天咱們碰撞出一個 idea，明天就有一幫哥們把他變爲一個工具或者小產品。創新被人發現後還會快速的發展成一系列生態。這些事情天天都在發生，對於咱們工具平臺來講，應該成爲一個載體，將最優秀的創新落地在平臺之上，促進類似產品的融合避免重複造輪子，也能夠推廣引流，作強作大，造成正向循環。

• 全棧文化：如今都在講 devops，但沒有工具承載的 devops 基本上是空談，當咱們平臺能夠幫助 dev 自動完成 ops 工做，或者引導促進知識學習時，才能作到研發、測試、運維協做的無死角。

• 精益文化：這個纔是咱們一站式平臺的理念所在：基於價值的交付，基於數據的準確度量，幫助開發或者領導者評估產品價值和優化團隊效率。

好，以上就是咱們對阿里內部研發工具建設上的一些實踐，但願可以拋磚引玉，共同探討。

兩大挑戰：質量和效率

接下來咱們探討一個話題，質量與效率，這多是工程領域一個永恆的話題，咱們今天就聚焦在互聯網場景下，咱們的軟件怎麼來解決既要又要還要的問題。

先看下在互聯網時代咱們的一些挑戰：

當交付速度決定市場：咱們 CTO 曾說過，研發工具要保障一個 idea 從誕生到上線在 2 周內完成，快速試錯，不行就幹掉，好了就拉一幫人作大作強。對於傳統研發方式來講，這彷佛很是困難，可是卻真實發生了。

在這個前提下，咱們的質量效率將如何選擇？

開着飛機換引擎會成爲常態？基於咱們前面的假設，先佔領市場，再不斷迭代優化，基本已經成爲咱們軟件研發的共識。如今若是有人說，咱們是開着飛機換飛機，我可能都只能「呵呵」一聲，由於咱們本身就常常這麼幹，對吧。

持續集成面臨挑戰

再來看咱們持續集成面臨的挑戰：

1. 缺乏測試覆蓋的持續集成成爲負擔。當咱們單測、API 測試作的很差的時候，經過流程強加的持續集成基本上是自欺欺人，要不就是不穩定，要不就是沒效果。

2. 測試團隊轉型，開發全棧致使的質量降低。有這麼多需求，沒時間寫測試，或者保姆式服務享受慣了，本身沒這個意識，等等等等。

3. 測試環境互相依賴產生不穩定因素，在阿里集成環境問題應該是研發過程當中的一大痛點。

看了這麼多問題，咱們須要思考，除了推進完善測試，咱們還能作什麼？

從工具要效率

好，我今天要講的是，從工具要效率，質量與效率並重。首先咱們看下咱們從哪裏能得到效率？

• 第一個快速反饋，我想對於效率咱們首先能想到的詞是快，也就是快速反饋。加快構建速度，加快回歸速度。

• 第二個是協做，由於每每溝通成本是程序員的一大開銷，並且我們還不太擅長，對吧，常常會發現 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。

國際化和私有云的轉變

說到交付這個話題，傳統企業必定不陌生，並且能夠說是絕對的專家。如今阿里這樣的互聯網公司面臨着新的交付問題。當咱們要把電商體系附能給合資公司怎麼辦，咱們要把基礎設施和完整阿里技術體系輸出該怎麼辦，當咱們應用巨多，造成網狀依賴之後怎麼辦？聽着就是一個很龐大的事情是否是？

目前咱們的兩個交付變化，從統一交付變爲分批交付，好比咱們先輸出電商中臺，再輸出電商上層業務應用。從總體交付變爲分塊交付，當所有輸出後，要進行版本迭代，如此大的應用規模沒法在作總體交付，此時就須要進行分塊交付。並且這個塊可能每次都會存在差別。這無疑對工具帶來了新的挑戰。

交付效率挑戰

咱們接着說效率，我這裏列了三點：

1. 快速搭建：咱們須要低成本的一鍵建立環境，復現問題，或者建立交付版本的集成測試環境。

2. 測試迴歸：當環境中存在多個版本服務怎麼搞，並且怎麼作到足夠得快

3. 鏈路管理：交付的過程能不能作成一鍵式，交付的版本可否可視可控，避免交付風險。

下面咱們針對以上三點舉例說明。

 交付過程探索

在這裏我把交付過程寫到了這個 pipeline 裏，依賴識別，對比迴歸，快速搭建，精準迴歸，一鍵交付

首先看依賴識別，爲何要作依賴識別，剛纔提到了，當個人應用數量很是大，而且網狀依賴很是複雜時，讓人來識別依賴關係已經不靠譜了。並且我要交付一個功能，若是牽一髮動全身的讓全部關聯應用來次總體輸出，涉及的團隊太多基本也不可持續。所以必定要工具來完成自動的依賴識別。藉助全鏈路調用數據徹底能夠作到這一點。

好比我修改了 A1 這個版本，經過鏈路數據結合交付端鏈路快照，發現必須順帶着交付 B1 和 C1 兩個版本，此時系統幫我圈定了一個交付集，後續的測試工做能夠基於此來開展。

集成測試開始前，咱們能夠藉助剛介紹的雙引擎測試平臺進行數據回放，對比測試，確認對交付端數據的影響。

 集成測試

接下來咱們將進入集成測試階段，首先是快速搭建，經過應用容器編排，基於中間件隔離，咱們能夠很輕鬆的將 A一、B一、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 機器人會更加智能。