DevOps三步工作法的第一步：建立全生命周期管理能力
全生命周期管理(ALM)領(lǐng)域作為企業(yè)DevOps實(shí)踐的總體支撐，應(yīng)該說(shuō)是DevOps領(lǐng)域中最為重要的實(shí)踐領(lǐng)域，也是所有其他實(shí)踐的基礎(chǔ)設(shè)施?，F(xiàn)在很多企業(yè)都非常重視CI/CD自動(dòng)化工具的引入和推廣，但是對(duì)ALM的建設(shè)的重視程度并不夠。CI/CD的火爆很大程度上是被Docker和DevOps的熱潮帶動(dòng)的，但CI/CD自動(dòng)化只是提升團(tuán)隊(duì)效率的一個(gè)環(huán)節(jié)，如果沒有ALM工具的支撐，CI/CD也只是空中樓閣，無(wú)法起到整體優(yōu)化團(tuán)隊(duì)工作效率的作用，甚至局部的效率提高還會(huì)造成團(tuán)隊(duì)的不適應(yīng)甚至抵觸。如果管理者看不到自動(dòng)化所產(chǎn)出的價(jià)值提升，團(tuán)隊(duì)感受不到自動(dòng)化所帶來(lái)的效率改進(jìn)，這一切的問(wèn)題都應(yīng)該歸根于企業(yè)沒有建立端到端的研發(fā)數(shù)據(jù)鏈，數(shù)據(jù)不打通，問(wèn)題的反應(yīng)永遠(yuǎn)只是局部的，無(wú)法從問(wèn)題的表象跟蹤到問(wèn)題的根源。《鳳凰項(xiàng)目》中所提到的DevOps三步工作法的***步：建立全局觀;其實(shí)是后續(xù)的建立反饋和持續(xù)改進(jìn)的基礎(chǔ)。CI/CD自動(dòng)化在DevOps中所起到的作用更多的是加快反饋速度，但在沒有建立全局觀的情況下一味的進(jìn)行反饋其實(shí)是沒有作用的。
就研發(fā)數(shù)據(jù)鏈來(lái)說(shuō)，下圖所展示的《軟件研發(fā)管理過(guò)程全景》中每個(gè)元素以及元素之間的鏈接就是ALM平臺(tái)所最關(guān)注的重點(diǎn)。只有建立了完整的研發(fā)數(shù)據(jù)模型，有了這些關(guān)系，我們才能從整體上對(duì)研發(fā)效率進(jìn)行評(píng)估，找到瓶頸，進(jìn)而改進(jìn)。建立這個(gè)模型的過(guò)程其實(shí)就是DevOps三步工作法的***步：建立全局觀。
(說(shuō)明：以上的全景圖是基于敏捷開發(fā)模式的，在傳統(tǒng)瀑布模式下，中間的項(xiàng)目計(jì)劃一般是從“架構(gòu)模型”過(guò)來(lái)的，而不是從“條目化需求”過(guò)來(lái)的)
在全生命周期管理實(shí)踐中，工具的使用是非常重要的一環(huán)。我時(shí)常把ALM系統(tǒng)比作研發(fā)的ERP，而實(shí)際上就是這樣一種關(guān)系，ALM平臺(tái)就是研發(fā)的信息系統(tǒng)。在所有的ALM系統(tǒng)中，跟蹤都是最基本的模塊，比如：VSTS/TFS中的工作項(xiàng)跟蹤，或者Atlassian產(chǎn)品中的Jira工具都是專注于這個(gè)領(lǐng)域的成功產(chǎn)品。但是我們也應(yīng)該注意到上圖中除了對(duì)事務(wù)或者內(nèi)容的跟蹤以外，我們還需要把代碼，用例，版本和環(huán)境也作為跟蹤的一部分。要做到這一點(diǎn)，工作跟蹤與配置管理，與自動(dòng)化系統(tǒng)的數(shù)據(jù)鏈路打通就變成了一種必須。
在這種場(chǎng)景下，一體化的工具(如：微軟的VSTS/TFS)就發(fā)揮出了它的優(yōu)勢(shì)，因?yàn)閮?nèi)置了包括工作跟蹤，測(cè)試管理，代碼庫(kù)(GIT)和自動(dòng)化系統(tǒng)(CI/CD);對(duì)于以上全過(guò)程的數(shù)據(jù)采集就變得易如反掌，同時(shí)配合后臺(tái)的企業(yè)級(jí)數(shù)據(jù)挖掘和分析引擎，讓研發(fā)數(shù)據(jù)鏈的建立，數(shù)據(jù)清洗和挖掘工作全自動(dòng)化，不再需要另外投入精力從不同的系統(tǒng)中抓取數(shù)據(jù)并進(jìn)行ETL聚合等操作。而使用相互獨(dú)立的過(guò)程跟蹤(如JIRA, redmine)，配置管理(如SVN，GitHub/GitLab，BitBucket)，測(cè)試管理(如：QC, TestLink)，缺陷管理(如：Bugzilla)和自動(dòng)化(如：Jenkins)工具，要建立完整的研發(fā)端到端數(shù)據(jù)鏈就必須另外建設(shè)獨(dú)立的數(shù)據(jù)挖掘和分析平臺(tái);這部分工具不僅投資巨大，而且難度很高。這后一種場(chǎng)景在企業(yè)信息化建設(shè)中也是一種常見的誤區(qū)，一般稱為煙囪式建設(shè)或者信息孤島效應(yīng)，大多數(shù)企業(yè)管理者都會(huì)希望采用各個(gè)領(lǐng)域最專業(yè)的系統(tǒng)來(lái)建設(shè)，***發(fā)現(xiàn)每個(gè)領(lǐng)域你都用不到那個(gè)系統(tǒng)功能的20%，還要再花費(fèi)巨大的時(shí)間和資金投入去進(jìn)行系統(tǒng)集成和數(shù)據(jù)打通。
在研發(fā)領(lǐng)域，能夠把管理者最關(guān)心的數(shù)據(jù)從團(tuán)隊(duì)成員的指尖送到管理者的面前，其實(shí)是這些系統(tǒng)最重要的功能之一，如下圖：
類似以下這張報(bào)表，如果沒有完整的研發(fā)數(shù)據(jù)鏈和數(shù)據(jù)模型，是很難做到的。
我們一般稱此報(bào)表為：項(xiàng)目/產(chǎn)品交付進(jìn)度，它不僅僅展示了事務(wù)工作的進(jìn)度(開發(fā)進(jìn)度一欄)，同時(shí)也在每個(gè)需求維度上展示了質(zhì)量情況(測(cè)試用例通過(guò)率和bug修復(fù)率)。這樣對(duì)于管理人員來(lái)說(shuō)，你無(wú)需知道細(xì)節(jié)就可以對(duì)某一特定需求的交付能力進(jìn)行判斷。
為了生成以上這張報(bào)表，我們需要聚合至少3類數(shù)據(jù)：
1. 不同層級(jí)需求上的進(jìn)度情況：需求管理過(guò)程中，為了能夠給不同的角色進(jìn)行分工，或者區(qū)分不同類型或者粒度的需求，我們一般都會(huì)將需求組織成樹形結(jié)構(gòu);并在***層節(jié)點(diǎn)上掛接開發(fā)任務(wù)并分配給團(tuán)隊(duì)成員;團(tuán)隊(duì)成員在任務(wù)粒度上的進(jìn)度反饋需要一層一層累加到最終用戶可見的需求上;這個(gè)數(shù)據(jù)模型的建立主要通過(guò)工作跟蹤模塊來(lái)完成，數(shù)據(jù)分析的建立則需要經(jīng)過(guò)一定ETL處理的數(shù)據(jù)倉(cāng)庫(kù)配合。
2. 測(cè)試進(jìn)度：測(cè)試管理涉及測(cè)試事務(wù)管理和測(cè)試內(nèi)容管理兩個(gè)部分，事務(wù)管理的是人員的工作量和進(jìn)度，而內(nèi)容管理的是產(chǎn)出的具體測(cè)試用例和執(zhí)行結(jié)果。實(shí)際工作中，我們必須能夠同時(shí)管理這2個(gè)維度的工作，同時(shí)將測(cè)試內(nèi)容的結(jié)果反饋到具體的需求上，這樣對(duì)交付才有作用。這部分的數(shù)據(jù)通過(guò)ETL進(jìn)行處理時(shí)必須能夠和前面的需求粒度產(chǎn)生數(shù)據(jù)聯(lián)系。
3. 缺陷進(jìn)度：缺陷一般是測(cè)試產(chǎn)出或者用戶(包括團(tuán)隊(duì)成員)的反饋，包括修復(fù)的情況。同樣，這部分?jǐn)?shù)據(jù)也需要在ETL的時(shí)候和需求粒度建立聯(lián)系。
另外一個(gè)研發(fā)數(shù)據(jù)挖掘和分析的很有意思的應(yīng)用是Code Lens，如下圖：
通過(guò)整合代碼庫(kù)歷史記錄與工作項(xiàng)跟蹤信息，可以在開發(fā)人員編輯代碼的同時(shí)在后臺(tái)分析出當(dāng)前的代碼塊在歷史上曾經(jīng)出現(xiàn)過(guò)哪些問(wèn)題/bug，幫助開發(fā)人員定位問(wèn)題。
我們?cè)谘邪l(fā)管理上往往陷入一個(gè)誤區(qū)，就是讓具體做事情的人(程序員、測(cè)試人員等)覺得他們所做的任務(wù)更新，代碼提交都是給別人做的;自己完全體會(huì)不到任何好處;久而久之，就失去了主動(dòng)性，認(rèn)為管理的事情跟自己無(wú)關(guān)，采取不配合甚至抵觸，更有甚者則提供假數(shù)據(jù)蒙混過(guò)關(guān)。這其實(shí)不是開發(fā)人員的問(wèn)題，造成這種狀況的原因是我們沒有讓開發(fā)人員從自己所提供的數(shù)據(jù)中獲取價(jià)值。如果我們能夠提供更多類似Code Lens這種開發(fā)輔助工具，開發(fā)人員一定是樂(lè)于參與其中的。我們?cè)贒evOps中常說(shuō)要打破部門壁壘，建立協(xié)作;這些不能只靠做游戲，我們還需要為流水線中的每個(gè)角色提供實(shí)打?qū)嵉膬r(jià)值反饋，才能讓大家真正成為一個(gè)整體。
簡(jiǎn)單總結(jié)一下，全生命周期管理平臺(tái)數(shù)據(jù)分析的價(jià)值有二：
- ***：為管理者提供更多的Insight，讓所有的細(xì)節(jié)串接成為研發(fā)全景圖，提升管理者對(duì)實(shí)際狀況的把控能力。只有看到才能評(píng)估，只有評(píng)估才能管理
- 第二：為開發(fā)人員提供更多的Insight，讓流水線中的每個(gè)環(huán)節(jié)都能獲得對(duì)他們有價(jià)值的反饋。只有反饋了價(jià)值才有正能量，只有正能量才能形成協(xié)作
因此，我們決定從2017年5月份開始維護(hù) “VSTS/TFS功能發(fā)布時(shí)間軸”，這個(gè)頁(yè)面將跟隨VSTS的三周發(fā)布頻率，定期更新，同時(shí)對(duì)新發(fā)布的功能進(jìn)行簡(jiǎn)要介紹。希望能夠幫助廣大企業(yè)和開發(fā)團(tuán)隊(duì)及時(shí)了解這一工具的***動(dòng)態(tài)，持續(xù)優(yōu)化自己的DevOps實(shí)踐。
我曾經(jīng)為多家大型企業(yè)實(shí)施過(guò)微軟的VSTS/TFS全生命周期管理平臺(tái)，這些企業(yè)最看重的一點(diǎn)其實(shí)就是是TFS在研發(fā)數(shù)據(jù)分析上所體現(xiàn)的開箱即用能力。這些年，微軟TFS(包括在線的VSTS)的版本更新越加頻繁(從每2年一個(gè)版本提升到每3周一個(gè)版本)，我們的客戶非常關(guān)心這些新特性的發(fā)布情況，同時(shí)我們自己也需要不停的跟進(jìn)這些新特性以便給客戶提供***化的方案。
頁(yè)面地址：http://devopshub.cn/vsts-tfs-feature-timeline/。
這個(gè)頁(yè)面分為2部分，同時(shí)顯示VSTS在線版的發(fā)布時(shí)間和TFS企業(yè)版的發(fā)布版本號(hào)，中間的特性列表中包含指向這些功能介紹的鏈接。我們會(huì)逐步將這些功能的介紹鏈接翻譯成中文，讓國(guó)內(nèi)的團(tuán)隊(duì)能夠***時(shí)間了解這些功能的變化。
1. 開發(fā)中的功能列表
2. .已經(jīng)發(fā)布的功能列表
這次，我們還同時(shí)發(fā)布了2017年5月11日的VSTS迭代更新說(shuō)明：
http://devopshub.cn/2017/05/19/vsts-update-may-11-team-services/
【本文為51CTO專欄作者“徐磊”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過(guò)作者微信公眾號(hào)devopshub獲取授權(quán)】
