全生命週期管理（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週一個版本），我們的客戶非常關心這些新特性的釋出情況，同時我們自己也需要不停的跟進這些新特性以便給客戶提供最優化的方案。

這個頁面分為2部分，同時顯示VSTS線上版的釋出時間和TFS企業版的釋出版本號，中間的特性列表中包含指向這些功能介紹的連結。我們會逐步將這些功能的介紹連結翻譯成中文，讓國內的團隊能夠第一時間瞭解這些功能的變化。

1.開發中的功能列表

2.已經發布的功能列表

文章來自微信公眾號：DevOps