全生命週期管理領域做爲企業DevOps實踐的整體支撐

全生命週期管理（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實踐。

 

原文來自：http://www.yunweipai.com/archives/18136.html

本文地址：https://www.linuxprobe.com/devops-build-management.html編輯員：郭建鵬，審覈員：逄增寶