DevOps三步工作法的第一步：建立全生命周期管理能力

作者：徐磊 2017-05-23 15:12:29

就研發數據鏈來說，只有建立了完整的研發數據模型，有了這些關系，我們才能從整體上對研發效率進行評估，找到瓶頸，進而改進。建立這個模型的過程其實就是DevOps三步工作法的第一步：建立全局觀。

[[191819]]

全生命周期管理(ALM)領域作為企業DevOps實踐的總體支撐，應該說是DevOps領域中最為重要的實踐領域，也是所有其他實踐的基礎設施。現在很多企業都非常重視CI/CD自動化工具的引入和推廣，但是對ALM的建設的重視程度并不夠。CI/CD的火爆很大程度上是被Docker和DevOps的熱潮帶動的，但CI/CD自動化只是提升團隊效率的一個環節，如果沒有ALM工具的支撐，CI/CD也只是空中樓閣，無法起到整體優化團隊工作效率的作用，甚至局部的效率提高還會造成團隊的不適應甚至抵觸。如果管理者看不到自動化所產出的價值提升，團隊感受不到自動化所帶來的效率改進，這一切的問題都應該歸根于企業沒有建立端到端的研發數據鏈，數據不打通，問題的反應永遠只是局部的，無法從問題的表象跟蹤到問題的根源。《鳳凰項目》中所提到的DevOps三步工作法的***步：建立全局觀;其實是后續的建立反饋和持續改進的基礎。CI/CD自動化在DevOps中所起到的作用更多的是加快反饋速度，但在沒有建立全局觀的情況下一味的進行反饋其實是沒有作用的。

就研發數據鏈來說，下圖所展示的《軟件研發管理過程全景》中每個元素以及元素之間的鏈接就是ALM平臺所最關注的重點。只有建立了完整的研發數據模型，有了這些關系，我們才能從整體上對研發效率進行評估，找到瓶頸，進而改進。建立這個模型的過程其實就是DevOps三步工作法的***步：建立全局觀。

(說明：以上的全景圖是基于敏捷開發模式的，在傳統瀑布模式下，中間的項目計劃一般是從“架構模型”過來的，而不是從“條目化需求”過來的)

在全生命周期管理實踐中，工具的使用是非常重要的一環。我時常把ALM系統比作研發的ERP，而實際上就是這樣一種關系，ALM平臺就是研發的信息系統。在所有的ALM系統中，跟蹤都是最基本的模塊，比如：VSTS/TFS中的工作項跟蹤，或者Atlassian產品中的Jira工具都是專注于這個領域的成功產品。但是我們也應該注意到上圖中除了對事務或者內容的跟蹤以外，我們還需要把代碼，用例，版本和環境也作為跟蹤的一部分。要做到這一點，工作跟蹤與配置管理，與自動化系統的數據鏈路打通就變成了一種必須。

在這種場景下，一體化的工具(如：微軟的VSTS/TFS)就發揮出了它的優勢，因為內置了包括工作跟蹤，測試管理，代碼庫(GIT)和自動化系統(CI/CD);對于以上全過程的數據采集就變得易如反掌，同時配合后臺的企業級數據挖掘和分析引擎，讓研發數據鏈的建立，數據清洗和挖掘工作全自動化，不再需要另外投入精力從不同的系統中抓取數據并進行ETL聚合等操作。而使用相互獨立的過程跟蹤(如JIRA, redmine)，配置管理(如SVN，GitHub/GitLab，BitBucket)，測試管理(如：QC, TestLink)，缺陷管理(如：Bugzilla)和自動化(如：Jenkins)工具，要建立完整的研發端到端數據鏈就必須另外建設獨立的數據挖掘和分析平臺;這部分工具不僅投資巨大，而且難度很高。這后一種場景在企業信息化建設中也是一種常見的誤區，一般稱為煙囪式建設或者信息孤島效應，大多數企業管理者都會希望采用各個領域最專業的系統來建設，***發現每個領域你都用不到那個系統功能的20%，還要再花費巨大的時間和資金投入去進行系統集成和數據打通。

在研發領域，能夠把管理者最關心的數據從團隊成員的指尖送到管理者的面前，其實是這些系統最重要的功能之一，如下圖：

類似以下這張報表，如果沒有完整的研發數據鏈和數據模型，是很難做到的。

我們一般稱此報表為：項目/產品交付進度，它不僅僅展示了事務工作的進度(開發進度一欄)，同時也在每個需求維度上展示了質量情況(測試用例通過率和bug修復率)。這樣對于管理人員來說，你無需知道細節就可以對某一特定需求的交付能力進行判斷。

為了生成以上這張報表，我們需要聚合至少3類數據：

1. 不同層級需求上的進度情況：需求管理過程中，為了能夠給不同的角色進行分工，或者區分不同類型或者粒度的需求，我們一般都會將需求組織成樹形結構;并在***層節點上掛接開發任務并分配給團隊成員;團隊成員在任務粒度上的進度反饋需要一層一層累加到最終用戶可見的需求上;這個數據模型的建立主要通過工作跟蹤模塊來完成，數據分析的建立則需要經過一定ETL處理的數據倉庫配合。

2. 測試進度：測試管理涉及測試事務管理和測試內容管理兩個部分，事務管理的是人員的工作量和進度，而內容管理的是產出的具體測試用例和執行結果。實際工作中，我們必須能夠同時管理這2個維度的工作，同時將測試內容的結果反饋到具體的需求上，這樣對交付才有作用。這部分的數據通過ETL進行處理時必須能夠和前面的需求粒度產生數據聯系。

3. 缺陷進度：缺陷一般是測試產出或者用戶(包括團隊成員)的反饋，包括修復的情況。同樣，這部分數據也需要在ETL的時候和需求粒度建立聯系。

另外一個研發數據挖掘和分析的很有意思的應用是Code Lens，如下圖：

通過整合代碼庫歷史記錄與工作項跟蹤信息，可以在開發人員編輯代碼的同時在后臺分析出當前的代碼塊在歷史上曾經出現過哪些問題/bug，幫助開發人員定位問題。

我們在研發管理上往往陷入一個誤區，就是讓具體做事情的人(程序員、測試人員等)覺得他們所做的任務更新，代碼提交都是給別人做的;自己完全體會不到任何好處;久而久之，就失去了主動性，認為管理的事情跟自己無關，采取不配合甚至抵觸，更有甚者則提供假數據蒙混過關。這其實不是開發人員的問題，造成這種狀況的原因是我們沒有讓開發人員從自己所提供的數據中獲取價值。如果我們能夠提供更多類似Code Lens這種開發輔助工具，開發人員一定是樂于參與其中的。我們在DevOps中常說要打破部門壁壘，建立協作;這些不能只靠做游戲，我們還需要為流水線中的每個角色提供實打實的價值反饋，才能讓大家真正成為一個整體。

簡單總結一下，全生命周期管理平臺數據分析的價值有二：

***：為管理者提供更多的Insight，讓所有的細節串接成為研發全景圖，提升管理者對實際狀況的把控能力。只有看到才能評估，只有評估才能管理

第二：為開發人員提供更多的Insight，讓流水線中的每個環節都能獲得對他們有價值的反饋。只有反饋了價值才有正能量，只有正能量才能形成協作

因此，我們決定從2017年5月份開始維護 “VSTS/TFS功能發布時間軸”，這個頁面將跟隨VSTS的三周發布頻率，定期更新，同時對新發布的功能進行簡要介紹。希望能夠幫助廣大企業和開發團隊及時了解這一工具的***動態，持續優化自己的DevOps實踐。

我曾經為多家大型企業實施過微軟的VSTS/TFS全生命周期管理平臺，這些企業最看重的一點其實就是是TFS在研發數據分析上所體現的開箱即用能力。這些年，微軟TFS(包括在線的VSTS)的版本更新越加頻繁(從每2年一個版本提升到每3周一個版本)，我們的客戶非常關心這些新特性的發布情況，同時我們自己也需要不停的跟進這些新特性以便給客戶提供***化的方案。

頁面地址：http://devopshub.cn/vsts-tfs-feature-timeline/。

這個頁面分為2部分，同時顯示VSTS在線版的發布時間和TFS企業版的發布版本號，中間的特性列表中包含指向這些功能介紹的鏈接。我們會逐步將這些功能的介紹鏈接翻譯成中文，讓國內的團隊能夠***時間了解這些功能的變化。

1. 開發中的功能列表