DevOps是很全面的概念，站在某一角度或少只能代表一部分看法。特別在大型企業，不同團隊有不同的職責，決定了各自會關注不同的方向。
本次會場可以說是DOIS主辦方的一次突破性嘗試，三位講師來自騰訊的不同部門，日常工作也是各司其職。我們通過一個上午的分享，從研發過程鏈條的前中後三個不同的視角來分享對DevOps的解讀和看法。
本文是DOIS大會騰訊專場研發管理方面的分享內容。
筆者來自騰訊技術工程事業群研發管理部，該部門提供的服務支撐了全騰訊業務，本次分享聚焦於DevOps中的敏捷研發和配置管理。很多朋友問起說騰訊這麼大的公司，那麼內部的研發是怎樣做的，研發效率是怎樣保證的？
我們在以前的分享也提到過，騰訊有種類繁多的廣泛的產品線，產品數量多。下圖列出了一部分，更多的產品是沒能列上的。
在這些產品背後是騰訊15,000~16,000名技術人員，這裡包括的不只是開發，也包含測試和運維。而產品員工大約是6000左右，包含了所有的產品經理、運營、遊戲策劃和項目經理。合計總人數大約22,000左右。
從研發效率來說，單位人員所提供的產品能力，體現了整個集團的人均研發效率。騰訊用數量並不太多的員工人數，維持瞭如此多款不同產品，我把其中研發效率的關鍵因素歸結為4點：
1.僱傭傑出的研發和產品人員
2.由下而上自組織的敏捷
3.自動化的研發工具體系
4.科學高效的質量控制能力
今天的分享著重來看第二點，也就是“敏捷”對於騰訊集團這樣的大型企業代表著什麼。
研發的現狀
研發過程中主要有兩種角色，分別是產品和研發。產品經理把需求排進需求池，和研發勾兌好，經過線上線下若干輪pk，劃分優先級排進迭代，研發團隊經過內部溝通，做好架構設計，然後把需求拆分給不同的人來實現，也就是任務分配。之後，開發開始寫代碼，寫代碼的過程中又需要各種各樣的溝通，比如有些依賴或者技術接口，再比如產品需求發現有些之前沒想到的疑問回去勾兌。等到功能大致開發好，測試開始介入，這個時候產品、開發和測試坐在一起，又要核對測試的需求，在測試過程當中還要勾兌開發環境。最後，在測試當中發現的問題，又要和產品和研發一起識別和跟蹤。
再進一步，從迭代規劃開始，研發團隊先要對根據產品節奏，對自己的版本做規劃。當然不同形態的產品，規劃出的結果是大相徑庭的，如果是互聯網產品，那麼規劃往往與發佈節奏有關，如果是交付給用戶的產品，比如說騰訊雲TCE和TSTACK，這些產品要對不同的客戶有不同定製，版本規劃肯定又會和客戶交付有關。在有版本規劃之後，研發leader開始分活兒，那麼分得任務又開始與分支規劃有關，是要主幹開發呢？還是要特性分支開發呢？還是要一個人一個分支開發能？那麼怎麼規劃？此時研發Leader有責任規範研發團隊的作為，我們要改分支開發模式呢還是如何？之後提交、到合流、到缺陷反饋時候的自動化檢測，最後再到發佈交付都要怎麼做？仔細想想看，每個團隊在跑熟流程前，還有遇到問題解決問題的時候都要經過大量的溝通。這些溝通只能在產品團隊、研發團隊、質量團隊和CMO（也就是配置管理員）中內部消化。
（現代研發複雜的控制節點）
回想一下整個過程，即便沒有講細，也講了如此之多的步驟。卻還沒談怎麼寫代碼，反而把時間在規範、交流、溝通中浪費掉了。
回顧下互聯網時代早期，需求、迭代、IPM、Scrum、缺陷反饋等等這些概念，其實並不流行。例如騰訊在Pony、Tony還寫代碼的時代，寫第一版QQ時，也未必真的瞭解IPM是什麼。舉一反三，在一個行業發展的初期，往往是研發效率最高的時刻。例如前兩年的AI圍棋，團隊可以只有很少的人就能實現突破性進展，可以說：越在行業初期，研發團隊越簡單幸福。
但是時代決定了大家不能一直這麼開心的走下去，因為軟件工程越來越複雜，版本越來越多，功能越來越強大，註定了研發團隊不可能一直是個小規模的組織。組織越大，個體之間的隔閡就越大，隔閡直接帶來的就是溝通成本的增加。
溝通是敏捷和DevOps的共性本質
Agile也好，極限編程也好，Scrum也好，這些“敏捷”實踐都是一種溝通的規範或者方法論。他們本質上解決的問題都是溝通上的問題——你不懂我，我不懂你，我要懂你，就要緊密的在一起。
可以說溝通效率的優化，是敏捷運動和DevOps運動的一個共性本質。DevOps說的什麼？研發和運維緊密的在一起。
敏捷方法論中，規範的是人與人之間的溝通。DevOps則更進一步，涵蓋了人與機器的溝通以及機器與機器的溝通。
DevOps進一步實現了人機的自動化對接。
在DevOps提供的全鏈路數字化鏈接的基礎上，下一步發展會是什麼？發人深省，細思極恐
那麼從集團層面想要提升效率，要在各種場景下優化溝通。怎麼樣優化溝通呢？在這方面騰訊做到了三件事：
騰訊在優化溝通上所做的三件事
第一點是在組織上減少職務鴻溝
本文不講企業管理，略過
第二點是信息化
這裡筆者放了幾張對比圖：
上例雖然用圖有些誇張，主要是為了闡明觀點便於理解：如果能用TAPD寫的幹嘛要去寫紙條，寫完了還得粘，粘完了還得撕，是一件累人的事。技術文檔亦然，能用文本格式化在代碼庫裡，為什麼要寫doc？
敏捷從誕生開始到現在，Scrum已經有20多年的歷史。如此漫長的時間段中，Scrum從理論層面上看幾乎沒有什麼變化。
但這20多年間，世界已經前行，特別是人們的溝通方式發生了鉅變。從口口相傳，到有電話，到PC，到Internet，到移動網絡，到智能設備，到微信等等，溝通的工具一直在升級換代。
代碼庫在公有云的外網雖然現在還沒和企業微信集成，但騰訊內的版本很早就實現了IM通知，比如在家休假，完全靠手機就可以瞭解到我們團隊的編碼進度，分支合併的消息都直接通過企業微信push到手機上，週末也都知道誰在加班。同樣對於TAPD，如果需求有變化，可以通過手機上企業微信直接查看。
在信息化上，新的概念是辦公無邊界，包含辦公桌上的PC，家的PC，移動終端和智能設備，使用統一的鑑權和認證方案，實現
研發過程中信息的無界傳達。第三點，確定統一的溝通體驗
騰訊在統一溝通體驗上非常有原則，我們知道騰訊有非常多不同形態的業務，導致在研發工具鏈上有很多不同的工具和體系。
但是，卻保障了最基本的溝通工具是統一的。
研發管理部負責了兩大研發平臺，TAPD是騰訊的敏捷研發平臺，承載了全公司的產品規劃、迭代、測試計劃、任務分配等等；Code是騰訊的源碼管理平臺，現在是工蜂，負責了全騰訊的代碼庫、資源文件、分支、審查、合併發佈到內部開源的研發鏈路。
所以即便騰訊如此講究內部賽馬，但最基礎溝通工具的統一還是沒丟。
保持高頻溝通應用的統一具有兩大好處，首先，它給集團內的業務合作減少了障礙，當兩個平時業務互不相關的部門相互合作時，因為系統和賬號相通，只需要加入對應的權限就行了；其次，統一溝通應用為集團內的人員流動創造了便利，一旦人員轉崗，在集團內統一的溝通體驗讓調動人可以快速適應工作。
DevOps系統的橋接形式
接下來看看DevOps在系統之間是怎樣互相橋接的。DevOps關注的兩塊過程改進，一個是研發的過程，一個是質量的過程。嚴格意義來說研發閉環是可以包含多個質量過程閉環的。那麼在這兩個流程的閉環中，都會涉及到若干種不同的工具。
特別在一些領域，一款工具很難滿足全部的需要。比如說移動項目用jenkins，遊戲也用就不太好，再比如說小型機，很難找到開源的CI工具做編譯。這就導致不同的業務形態會有不同的工具。為了讓整個系統流轉起來，工具和工具之間的相互調用，對於騰訊來說，最好的方式是通過鬆耦合。
松耦合的概念是支持但不依賴。系統和系統之間都通過通用的接口和Hooks互相調用。同時騰訊內網的研發系統，已經逐步使用OAuth代替傳統token驗證，來保證訪問的多方安全性。
先來看內置集成的例子，也就是平臺產品直接提供的功能，這裡舉的是TAPD中關聯工蜂的代碼倉庫。
第一步，TAPD的項目設置頁面，點關聯Git項目
第二步，認證TAPD的授權到工蜂，這裡是一個OAuthV2的授權框
第三步，選擇你要綁定的git項目，點確定完成
當push時，在評論帶上--tapdid這樣一個參數，就能把對應的提交點綁定到需求上。
只需三步，需求關聯你的代碼庫。
但是理想是豐滿的，現實是骨幹的。產品這樣設計的功能，並不是所有的用戶都買單，團隊往往需要根據自己的特性來定製流程。下面用微信安卓團隊例子看看開發團隊怎麼做。
整個團隊每月大概處理 300 ～ 500 個需求，平均每個人做10個，採用特性分支的協作模型項目，每月一個迭代，3到4個Feature Team並行開發。
這個是微信的使用的分支模型，可以看到它是一個典型的特性分支發佈模型。根據每個月的發佈節奏設置了關鍵分支。
先來看他們怎麼把需求和代碼關聯起來的，他們並不滿足於單純把需求和提交綁定，而是做了全方位的關聯：
項目的默認分支就是代表當前迭代，歷史發佈的版本、當前版本和計劃開發的未來版本，都對應每個月的保護分支和發佈TAG。每個需求則對應一個或多個Feature分支。
這是微信項目在TAPD一個迭代的需求頁面
這是合併請求頁面，他們要求開發自己把需求單粘進合併請求單裡：
如果格式不對，或者需求不存在，就自動提示你需要填寫正確的需求單。
同時如果產品經理說需求這個月還不能發佈，也能通過tapd的標識，來直接攔截合併請求單。
同樣和代碼庫集成的還有自動化掃描和測試流程，流程就不仔細說了，也是通過鬆耦合的方式來實現自動化調用。當掃描檢測失敗的時候自動阻攔合併請求，從代碼級別上攔截特性分支的合入。
（自動化質量檢測接口調用模型）
騰訊企業級研發平臺的要求
一個成熟的企業級研發系統，以代碼管理為例，至少要在這4個方面能達到基本要求：
存儲對騰訊來說，總容量必須無限大，單庫容量必須能支撐大型圖遊這樣級別的項目。
在管理層面，人員、權限、和項目必須做到企業可控，這一點也是硬性條件。
在網絡層面，騰訊因為有多個辦公地，其中還有海外的，想要訪問項目足夠快就要在鄰近節點部署環境，來節省專線的帶寬，那麼系統的多地就近訪問，在騰訊來說也是一個必備功能。
在安全方面更是硬性要求，不能因為一個員工今天和領導鬧矛盾就刪庫跑路數據就找不回來了，同時，業務系統也要滿足企業內各種各樣的合規和審查要求，比如查一下上個月某個項目組的訪問記錄。
騰訊工蜂正是在這些要求下給騰訊量身定做的系統，目前已經服務了包括微信在內數不清的騰訊業務。
在系統設計上，也考慮了行業先進的思想和經驗。系統直接集成了代碼檢視能力，支持高數量級的分支管理，支持會話式開發，在工作過程中的動向通過動態的模式展示，同時集成和定製能力是全方位的，每一個可以操作的功能基本都有它對應的API或Hooks。
在企業管理方面也做了多層加強
會後答問
問：騰訊為什麼選擇Git作為下一代代碼管理平臺？
騰訊大約在2015~2016年意識到上一代SCM的不足，在2015~2017年間，阿里、百度、微軟等公司已經全面切換Git，新一代的Git系統並非單純的Git，而是一套高度集成化，承載多項能力的效能平臺。新一代思想設計下的系統在使用過程中，潛移默化的大幅增加研發過程中的溝通效率，並能夠將研發過程沉澱下來。
問：如何看待Git和傳統SCM在權限組織上的差異？
Git在團隊實踐過程中，巧妙的培養的業務團隊拆分架構和組件的行為。幫助項目架構更合理的結構化拆分，這種劃分大項目為細粒度的行為反而有助於權限的分散管理。這是經過實踐所得出的結論。
問：看到ppt中出現了分支權限，能否解釋一下？
因為需要考慮大型項目的日常管理，很多項目組有至少幾十人的團隊，之後又拆分成幾個小團隊，在分支策略上，往往不同團隊要管理不同分支。此時，庫級別的權限能力就不夠用了，必須在分支上增加權限控制。這也是工蜂的一項特有功能，後續會進一步優化。
展會花絮
閱讀更多 騰訊技術工程 的文章
