[持續交付實踐] 研發協做平臺：從交付流水線到研發協做平臺

前言

2017年11月前，咱們基本上已經完成了Jenkins pipeline流水線上各個環節的設計和開發，這裏面囊括了編譯、部署、代碼檢查、單元自動化測試、接口自動化測試、UI自動化測試、專項自動化測試（APP專項/性能等）、發佈等一系列環節，完成了各個內建測試平臺與jenkins pipeline的結合,固然在團隊內部的應用上，還須要持續驅動。
這個時候Jenkins自身的侷限性就暴露出來了，Jenkins只是很好的解決了每一個應用交付流水線的問題，但隨着企業業務量的增長，研發團隊急劇擴張，研發中的各個環節，好比應用的管理，代碼庫的管理，開發測試環境的管理，發佈計劃的管理，發佈後的監控，研發質效的度量，輿情故障的管理等等都存在無數的痛點， 任何一個環節沒跟上都會嚴重影響研發的質量和效能。
下面是技術工程師天天的工做平常，立項，建代碼庫，申請資源，拉分支寫代碼，聯調測試，發佈到線上，設置監控點，質效分析和總結等等，這些活動存在於不一樣的平臺，天天在不停的重複，須要不停的和各個團隊溝通，不停的作研發平臺和技術棧的切換，因此咱們又回到持續交付的一個原則，若是有一件事讓你感受到痛苦，那麼就今早並儘量頻繁的去作。梳理出規範化的玩法，採用自動化的高效手段，用技術去解決這些讓咱們感受頭疼的問題。

 

 

這個時候就須要咱們進一步把思考層次從測試團隊提高到整個研發團隊、整個產品團隊的高度，不只僅只是想着測試工程師怎麼測試，更要想着整個研發團隊應該怎麼高效協同，把研發中全部的環節儘量的標準化、自動化、透明化，靠技術而不是一大堆管理規範來解決問題，從而造成一個完整的研發閉環。跳出測試執行的小圈子去思考質量，向左在開發階段保證編碼質量，向右在生產環境保障發佈質量，這也正是我所理解測試團隊要在devops/持續交付模式下保持競爭力的關鍵所在。

QA（EP）團隊的三個階段

只是從我的經歷的思考，可能不是很成熟。各個階段的建設沒有絕對的前後順序，但後面階段的效果會強依賴於前面階段的能力。
google從QA團隊逐步發展成了EP團隊，中間的過程也是從業務測試團隊，逐漸發展成質量效能平臺研發、提供測試賦能的團隊，這個過程會很漫長（對不少公司來講可能永遠看不到），但相信是趨勢。
第一階段：測試自動化，代碼層，接口層，UI層、APP專項/安全/性能等各專項環節的自動化測試，搭建自動化測試平臺。
第二階段：交付流水線化，把包括自動化測試在內的各個交付環節經過pipeline的方式進行串聯斜街，搭建持續交付平臺。
第三階段：研發協做智能化，除了pipeline流水線，延伸到代碼管理，應用管理，資源管理，發佈管理，監控管理，項目管理，研發工具雲等各個研發環節，向任何研發環節挖潛，提供一站式智能研發協做平臺。

 

 

技術範的公司如何開發、測試和發佈

應用爲中心的研發協做

創建公司級別的標準應用庫，以應用爲中心，這點很是重要，是整個研發協同活動的基石，應用信息對研發人員自然是親切的，它能夠直接對應一個服務，一個代碼庫，一個環境，一條流水線，一個監控job,一個質效數據。
咱們須要依靠應用這個維度，串聯整個研發協做過程，代碼、資源、流水線、監控、運維、故障、質效等等都是圍繞着應用維度來開展，開發、測試、運維、安全等等技術團隊也就能夠在各自平臺上去定義它的應用，並實現無縫的銜接。
應用有了標準庫，也就有了生命，有了生命週期的管理。應用再也不只是一個乾癟的代號或標識，而是一個活動集合一個工做系列。不管是新建和停用，都會影響到一系列的工做環節，固然這個過程咱們須要各類自動化串聯。

 

以應用新增和停用爲例
應用新增：應用基礎信息提交->業務線主管審覈->代碼推薦和初始化->資源申請
應用停用：停用應用->業務先主管審覈->運維審覈->代碼庫自動凍結->流水線job回收->資源自動回收->監控自動關閉等等

 

容器化的資源管理

開發，測試，預發，發佈，稍微上規模的互聯網技術團隊，上線前都會經歷這幾個階段，每一個階段分別對應一套環境。因此咱們至少會面對開發環境、測試環境、預發佈環境、正式環境，在沒有使用容器以前各套環境配置、軟件包、資源類型等等難以保持一致。
產品線若干條，數百個應用，每一個應用併發N個分支，有Java、NodeJS、PHP、C++、Android、IOS、中間件等等。
微服務和分支開發的背景下，應用和分支數量氾濫，各服務相互依賴耦合，資源管理複雜度和需求量劇增，難度不亞甚至更超過線上環境的管理。沒有趁手的利器，環境穩定性差，會致使開發和測試效率都十分低下，各個應用之間的開發工做互相block，從而拖垮整個團隊的項目研發。
幸虧咱們有了容器這個救命稻草，軟件包管理、目錄管理、基線變動、運維腳本等等經過一個dockfile就能夠規範解決，再經過分佈式配置中心（業內知名的如springcloud的config、百度的disconfig、攜程的apollo、淘寶的diamond等）實現對不一樣環境的配置管理，基本咱們就實現了環境的標準化以及運維服務的下沉，DevOps的理念才得以真正的落地。
一鍵化申請容器應用(還包括mysql、redis、mongdb等的標準組件)過程

 

研發環境特別痛苦的一個點是，每一個應用都會存在大量並行分支的開發。若是所有環境混在一塊兒，各個分支之間互相依賴互相干擾的狀況會讓人崩潰，而若是搞出幾套研發環境（好比常規分支、特性分支、緊急分支等），多套環境的維護量也一樣會讓人崩潰。
這裏比較好的一個實踐，就是區分出穩定環境（stable）和分支環境，而且將分支環境隔離。這裏的分支環境多是一個開發機，也多是一個測試服務器，針對某個需求相互依賴的應用分支可隔離在一個環境內，而非需求強依賴的應用則能夠直接鏈接穩定環境。
由於咱們的分佈式服務用的是dubbo,容器管理用的是K8S,要實現這點中間其實還涉及到很多對dubbo和K8S自身的改造。

 

流水線是DevOps的核心

要實現持續交付，核心在於Pipeline,要實現Pipeline，重點在於自動化測試。
如何經過自動化流水線，讓需求小批量流轉，實現軟件短週期的頻繁交付，在持續交付的文章裏已經寫了不少，這裏再也不贅述。經過研發協做平臺，咱們再也不徹底依賴於Jenkins千篇一概的界面和佈局，把Jenkins做爲基礎設施，而不是操做管理界面，這是研發協做平臺集成流水線技術的重點。
另外比較重要的一點是，有了pipeline咱們仍是須要有發佈計劃的管理。即便是在持續交付模式下，發佈操做仍然是一個嚴肅的事情，須要很是審慎的對待，好比除了pipeline的運行結果，還要包括codereview的結果，發佈窗口，人工檢查的結果等等，這些都須要在研發協做平臺上自動化進行結果聚合和控制。

 

 

一站式監控管理

圍繞應用，咱們有多維度立體式的監控體系，包括而不限於
撥測監控：系統有沒有問題？
全鏈路監控：系統哪裏有問題？
輿情監控：用戶反饋了什麼問題？
資源監控：主機網絡有沒有問題？
這裏要作的是聚合，腳本化的監控要頁面化，頁面化的監控要歸一化，經過應用的篩選，就能夠看到整個監控大盤的全貌，而且經過統一的應用報警設置，創建共同的響應機制。
以撥測監控爲例：

 

 

度量管理：DevOps儀表盤

管理大師彼得德魯克：若是你不能度量它，你就沒法改進它。
作事情應該以終爲始，發佈上線並非項目的重點，而是另一個迭代的開始，創建快速和持續的從右到作的反饋尤其重要，經過建設質量和效能的數據看板，讓整個交付過程更加透明，暴露出瓶頸點並持續改進，這是度量管理的核心意義。
列舉一些常見的度量點，這些都但願在應用的維度下系統展現，而不是在一個個內部平臺上去跳轉，去人工採集。
項目進度和風險大盤
需求完成率
項目及時率
代碼靜態分析結果
流水線執行頻率、時長和成功率
發佈執行頻率、時長和成功率
監控報警頻率和趨勢
線上故障狀況統計等

 

 

內部全雲化的工具平臺

技術團隊愈來愈大，開發、測試、運維、安全等各類工具平臺愈來愈多，各個BU在各個是技術方向上也都有創新的衝動，這必然也會致使不小的重複建設和資源浪費。
因此咱們開始嘗試內部雲化的工具平臺，包括內部的開發工具鏈平臺，測試工具鏈平臺，安全工具鏈平臺，運維工具鏈平臺等，將各類標準化技術平臺的能力輸送給各個業務線團隊，提高團隊總體質量和效能。

 

 

後記

春節前二寶出生，新添一枚千金，增長了無數喜悅也帶來無數忙碌，時不時有壇友問起後面的文章，卻總髮現難以靜心總結。不只僅是生活和工做的忙碌，也是在從pipeline到研發協做平臺這個過程當中，發現了太多的坑須要去填補。洋洋灑灑一篇文章下來，中間的無數細節其實都須要無數技術棧上的攻關，直至到如今，仍然感受有不少地方須要完善改進，有許多方向能夠追加。到了這個階段所作的其實已經遠不是傳統測試範圍內要作的事情，咱們須要考慮平臺整體架構，須要考慮編碼設計，須要本身去作交互設計，本身去作美工，咱們沒有全職的前端（雖然我也有不少辦法能夠要到前端資源，但更傾向去全棧開發），須要和公司內部大大小小的平臺作聯調和對接，須要在各個技術團隊落地應用。但這一切都頗有價值，團隊內部應用的效果讓整個研發小組（全職參與的其實沒有幾人）信心滿滿，人人充滿動力團隊迅速成長，因此....這會是一個招聘廣告麼呵呵，歡迎加入微醫。