前言
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到研發協作平台這個過程中，發現了太多的坑需要去填補。洋洋灑灑一篇文章下來，中間的無數細節其實都需要無數技術棧上的攻關，直至到現在，仍然感覺有很多地方需要完善改進，有許多方向可以追加。
到了這個階段所做的其實已經遠不是傳統測試范圍內要做的事情，我們需要考慮平台總體架構，需要考慮編碼設計，需要自己去做交互設計，自己去做美工，我們沒有全職的前端（雖然我也有很多辦法可以要到前端資源，但更傾向去全棧開發），需要和公司內部大大小小的平台做聯調和對接，需要在各個技術團隊落地應用。但這一切都很有價值，團隊內部應用的效果讓整個研發小組（全職參與的其實沒有幾人）信心滿滿，人人充滿動力團隊迅速成長，所以....這會是一個招聘廣告么呵呵，歡迎加入微醫。