在5月5日的DevOpsDays Beijing，騰訊CODE平臺產品經理mars分享介紹了騰訊研發工具體系，并通過兩個研發過程中的實踐案例，說明DevOps理念對于研發過程的優化作用，本文是這次分享內容的整理和延伸。

一、 騰訊擁有業界領先的研發效率

平均每研發人員單位時間釋放出的產品能力，即“研發效率”。

根據騰訊3月份最新發布的公司介紹，騰訊大約有15,000名研發人員。但是，騰訊卻有幾乎最為廣泛的業務線。在日常生活中，每個人都可以感受到騰訊產品的覆蓋寬度。更為甚之，騰訊還有著名的“內部賽馬”文化，同一類產品可能有多個團隊競爭，這意味著集團的產品線要有多份的研發能力以供賽馬。在這一切的背后，必須以高效的研發能力來應對保障。

研發效率是是指單位研發人員負責輸出的產品能力，統計上就是集團公司整體的產品能力，除以整家公司技術族人數。

那么，究竟是什么使騰訊擁有如此高效的研發能力呢？有以下幾點因素：

• 人的因素

在騰訊，有上萬名優秀的技術人員，感謝他們心懷夢想的工作，為企業和社會做出了重要貢獻。

• 敏捷文化

在騰訊，敏捷早已深入骨髓，已經是一種自發的行為。公司無需刻意強調，團隊已然踐行。

• 研發工具自動化

研發鏈上，騰訊具備完整的去中心化的工具體系。在這個體系中，自動化和便利性同等重要，并通過去中心化的機制保證組織末梢上的業務效率。

• 質量保障能力

騰訊有非常高效的質量控制能力——高效率的質量團隊、高效率的質量工具和高效率的方法論。

二、騰訊研發工具鏈

騰訊特有去中心化的研發工具體系，平臺之間使用松耦合的方式互相集成。

下圖中列出的工具系統大約占到騰訊內部工具平臺的1/8左右。若從圓心點畫每一條射線，都能找到一個完整的工具鏈。從圖中可以看出，有些工具平臺是公共的，而其他一些則是與業務相關的。

（騰訊研發工具鏈示意圖）

來看一下集團層面的公線工具。

騰訊的代碼管理和需求管理有統一的平臺，也就是說騰訊的源代碼統一由CODE平臺負責管理，其中主要是騰訊自研的Git平臺，而需求規劃系統統一由TAPD承擔。

除此之外對于DevOps很重要但又很容易被忽略的部分，是企業內部的一些關鍵設施，比如辦公網絡、知識管理、安全管理還有就是最最重要的企業IM。

特別是IM，國內在做DevOps解決方案時經常忽略，IM和DevOps系統適當集成，可以組成實時的信息傳遞中樞。IM與全鏈工具鏈如何結合是一個可以深挖的課題。騰訊在IM方面已經全面使用企業微信，DevOps有關的各個系統都在實時通知的能力上與企業微信做了內部整合。

（公線工具示意圖，虛線內）

再來看一下業務線，虛線內囊括了集成、測試、容器、部署、微服務等等工具，可以看到沿著中心每一條線，都能伸展出一條完整的研發和運維工具鏈。

（業務線工具示意圖，虛線內）

其中還有一些比較著名的系統，比如織云、藍鯨、WeTest、Bugly，在各自的領域上都十分完備，有很好的用戶體驗。

系統和系統之間的DevOps閉環是通過松耦合的模式互相銜接的：用Hooks觸發，再用API相互集成調用。實現一種去中心化的協作能力。

每個業務可以自行選用適于自己的系統，比如一個團隊可以使用MIG的RDM做編譯，用IEG的CodeCC做靜態代碼掃描，用QTA或者WeTest做自動化測試，再用織云來發布服務。而不會因為組織架構而拘泥于某一系列的研發工具。

另外每個業務都可以自行定制貼近自己的工具，這樣一旦業務形成規模，就能保證研發系統在需求上最快時間的響應，更加利于研發團隊快速優化自己的效率。

三、一個案例

騰訊的研發團隊，如何進行項目組織？

騰訊有一個研發項目，因為是個很重要的產品，所以對變更的管理是很在意的，這個團隊每月要處理300到500個需求或者任務，項目代碼放在騰訊TGit系統上，需求管理用騰訊的TAPD，

具體看一下這個項目是怎么組織的。

這是一個分支策略的示意圖，可以看到這個項目采用的多分支的管理模式，每個功能和需求都是在獨立的特性分支上開發的。和主流的Github Flow有些不一樣，最主要是項目的默認分支不是穩固的，它會在每個月把默認分支重設一遍，比如現在是五月，那么研發Leader就會把默認分支設置成May，所有這個月要發布的功能都向這個分支合并，等到May這個版本發布完之后就啟用六月份的June。

這種分支的管理模式的核心思想主要是用發布節奏來組織分支策略，這個模式對多團隊合作的大型項目來說有很多的優點。但這個不是本文的議題，有興趣的同學可以研究下。

本文要談的重點是左邊棕色區域的功能分支，300到500個功能分支，最終要被合入這個月發布的版本中去。可以想象一下臨近發版日的時候是什么樣子的。

首先，500個功能一定不會是均勻提交的，一般都得到月中或者月末才提交，因為這個月先要溝通需求，需求溝通PK差不多了，開發再去實現，實現完開發自己還要做些調試和測試。所以一個月月末的時候，這些分支的合并壓力就會很大。500個功能，假設核心團隊的三個技術Leader負責合入把控，就那么幾天時間，每個合并遇到問題還要和團隊一個一個溝通……別的事就沒法做了……

所以大型研發團隊的痛點，所有的矛盾和解決方案都指到了分支的合入控制這個點上。那么這個團隊怎樣解決的呢？

首先是關聯需求

在發起合并請求的時候，直接在描述里粘貼對應的需求鏈接，后臺有一個腳本會用正則判斷鏈接是否存在，格式是不是正確。

如果沒貼鏈接或者鏈接不對，腳本就會自動調用Git平臺的接口，阻止下一步操作，像左圖這樣顯示合并被阻止，同時自動用評論提示缺少需求鏈接，就是下圖的樣子。

在需求一側也可以控制這個功能是否可以合入。下圖的提示意思就是要在需求管理平臺，標記需求單位“可合入”的狀態，這個合并請求才能放行。

再來看在合并時質量自動化改進

同樣的，利用代碼平臺的接口，通過自動化腳本，可以實現質量的自動化能力。

可以看到這里構建是用jenkins，測試是用團隊自己調用的測試工具和靜態檢查工具完成的。

如果編譯和自動化測試沒通過，合并請求也會被阻止，直到開發人員推送了能測試通過的版本，才會放行。

在合并請求的列表上，直接顯示了合并請求的檢測狀態。可以看到每一個合并請求，后面都自動跟了檢測狀態，綠色的對號或者紅色的叉子，這對項目管理人員是很友好的，紅色的可以直接跳過不看了。

四、質量控制流程設計的三個要求

自動化、感知能力、控制能力

第一是自動化，流程必須被設計成全面的自動化。哪怕有一點點操作需要手工執行，到具體研發的場景里就有各種理由被遺忘，所以要盡可能保證全流程都是自動化無人工操作的，這里有三小點，自動觸發，自動檢測，還有自動上報。

第二個要點是感知能力，這里面主要談的是信息流。如何讓研發團隊有能力了解和自己去把控質量，那么一定要把信息流做到位，要讓研發團隊，特別是和這段代碼有關的相關人，清晰的知道整個質量驗證的進度情況。信息流，主要解決的是溝通的問題，如果信息流做的不好，溝通基本靠嘴，那么效率是非常的低的。

這里也有三個小點，是實時、可追溯、可配置。可配置的意思主要的目的是信息泛濫。

第三點講控制，就是如何防止低質量的模塊被發布，那么流程上就要能自動截斷低質量模塊的發布，這里面我們提到的解決方法是攔截合并，控制關鍵分支。當然這里有一個前提，是代碼管理系統必須要有攔截功能。

回過頭來看從編碼到發布的流程，在過去，質量檢測在發布前能夠介入的時機也就有合并前，合入后，封包后三個階段：

往常這三步需要分開來做，用DevOps思想解決的是，讓這幾個事情同時完成，形成一個質量驗證的快速閉環。在每次合并請求發起和更新的時候，都自動化的把整個事情完整做一遍。這樣保證每一個功能合入都是安全可靠的。

真的能實現完全自動化的差不多只有下圖紅框圈起來這些

五、第二個例子

RDM是騰訊米格（MIG）的集成工具平臺，主要功能是移動端應用集成編譯和發布管理。

第二個例子來自米格的RDM平臺

RDM是支撐MIG旗下所有移動端業務的工具平臺，最主要的功能是集成編譯，也有一些自動檢測和驗證的能力。

下圖是一張流程的示意圖，展示的是集成和質量工具與源代碼管理平臺的之間接口的互相調用。從分支push開始到靜態檢測、到構建、到自動的功能測試，集成在一個Pipeline里面。

下圖是RDM Pipeline 配置頁

Pipeline最先是拉代碼，然后是構建打包，檢測項有代碼風格、Coverity掃描、Sonar掃描，代碼重復率等等，編譯集成后，還聯合有一些移動端的自動化測試平臺和工具。

如下圖的對話框，每項檢測項目都可以設置他們是否能阻斷合并請求。

當合并請求發起或者更新時，Pipeline的顯示效果如下圖

在合并請求的頁面上顯示檢測正在進行，同時企業微信也彈出來提示，說明檢測開始了

檢測結果附在合并請求的動態墻上，這些都可以事后在代碼平臺上查詢到，實時的結果則通過企業微信推送。

如果檢測失敗就會阻止合并請求，之后如果開發新提交的代碼解決了這些問題，那么這里的合并請求會自動放行。

小結

上面這些例子，都是在合并請求上附加各種各樣的集成能力，利用自動化和流程化，來增強項目人員和管理者的感知，達到優化流程的目的。

一方面通過代碼平臺和IM的能力實現了實時可追溯的信息流。另一方面，通過代碼平臺阻斷低質量模塊的合入（這個阻斷能力需要代碼管理平臺支持）。并展示了在研發過程中的端到端打通能力（從代碼提交封包測試完成）。

六、開源和開放

騰訊研發工具鏈上工具的開源項目和開放能力

騰訊研發管理工具鏈的開源做得很早。其中有一些知名項目，例如藍鯨配置平臺（bk_cmdb）和Tars微服務解決方案（Tars），業界已經比較了解，可以在Github的騰訊賬號下搜索到。

騰訊研發工具鏈上開源過的工具和組件：

本文介紹幾個冷門項目：

GAutomator

看截圖很快能知道是互娛的項目，這個項目是個Unity的自動化測試框架，它是WeTest的其中一個模塊，WeTest是個真機測試云的解決方案，用成千上萬臺不同型號的手機跑各個機型的自動化測試。

Tscancode

同樣是來自互娛的TScanCode，做的是靜態代碼掃描，支持C++和Lua，幫你分析代碼中的潛在漏洞。

QTAF

QTA是SNG社交網絡質量部出品的自動化測試框架，承擔了SNG多數業務包括騰訊云的部分業務在內的自動化測試需求。支持移動APP、Windows程序、網頁、服務端、接口多種不同平臺的測試任務，開源的部分放出了Android和iOS的測試庫插件，分別是QT4A和QT4i，其中QTAF是其核心框架的核心模塊。有興趣交流可以在Github的項目上給項目組提issue。

七、總結

本文通過分享幾個研發過程優化的例子，說明了DevOps端到端的思想不僅僅是針對運維的，它還對研發管理，特別是質量控制很有價值，并且能夠直接改善研發團隊的體驗，減少溝通損耗，提高研發效率。同時也介紹了騰訊內部的實現經驗。在流程改進上還有很多的路徑或者體驗可以優化，希望與同行共勉。

請關注公眾號「騰訊技術工程官方號」

wechat ID：Tencent_TEG

后臺回復“devops”，獲取本文PPT原件

總結

以上是生活随笔為你收集整理的腾讯研发效率领先的秘密：高效率的工具的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。