[[186116]]

2010年，我曾在IBM供職，開(kāi)始參與DevOps相關(guān)的產(chǎn)品研發(fā)與實(shí)施工作。今天看來(lái)，我也許是國(guó)內(nèi)較早的DevOps踐行者。這兩年DevOps在國(guó)內(nèi)開(kāi)花結(jié)果的時(shí)候，我見(jiàn)到了很多錯(cuò)誤轉(zhuǎn)型的亂象。本文中，將為大家分享自己對(duì)DevOps行業(yè)發(fā)展的觀察，并向介紹DevOps轉(zhuǎn)型的路途中都有哪些陷阱。希望通過(guò)本文，大家能更夠撥云見(jiàn)日，真正的使DevOps成為企業(yè)生產(chǎn)力增長(zhǎng)的助推器。 

本文目錄：

一、軟件工程的發(fā)展

二、DevOps轉(zhuǎn)型陷阱

三、DevOps核心實(shí)踐

四、DevOps生態(tài)環(huán)境
 

一、軟件工程的發(fā)展

1、工具的發(fā)展

首先說(shuō)DevOps并不是一種工具，而是一種理念或者團(tuán)隊(duì)文化。為了實(shí)現(xiàn)這一種理念，于是就有一系列的軟件工程的支持工具(Computer Aid Software Engineering)。說(shuō)到CASE，就不得不說(shuō)一說(shuō)，兩個(gè)軟件巨頭：微軟和IBM。我們以他們的軟件工程之路，來(lái)說(shuō)明行業(yè)的發(fā)展歷程。 

早在1997年微軟就推出了可視化的開(kāi)發(fā)工具，Visual Studio(VS)，相信寫過(guò)C或者C++的同學(xué)們一定不會(huì)對(duì)這個(gè)工具陌生。接下來(lái).Net框架的誕生，讓微軟統(tǒng)一了開(kāi)發(fā)平臺(tái)的架構(gòu)，整個(gè)VisualStudio所支持的C#, VB, C++等可以編譯成中間語(yǔ)言，托管在.Net Framework之上運(yùn)行?？上菚r(shí)微軟足夠有錢，還在走閉門造車的路子。

.Net不僅不跨平臺(tái)，整個(gè)VS的架構(gòu)也比較封閉，只有商用的軟件才會(huì)為VS生產(chǎn)插件。與此風(fēng)格截然不同的IBM，走開(kāi)放路子的Eclipse在2004年誕生了，Eclipse的誕生漸漸拉開(kāi)了開(kāi)源軟件對(duì)抗企業(yè)軟件的序幕。 

進(jìn)入2005年左右，軟件工具進(jìn)入?yún)f(xié)同開(kāi)發(fā)的階段，微軟推出了服務(wù)器端TFS (Team Foundation Server)。TFS的推出，使得多個(gè)程序員可以方便的進(jìn)行代碼配置管理，任務(wù)管理，以及數(shù)據(jù)分析，構(gòu)建等工作。這時(shí)軟件開(kāi)發(fā)工具已經(jīng)開(kāi)始和軟件過(guò)程相結(jié)合，將敏捷的思想注入到工程實(shí)踐中。在IBM一方，Eric Gamma(相信看過(guò)GOF設(shè)計(jì)模式，以及一些列Eclipse書(shū)籍的同學(xué)們不會(huì)對(duì)這個(gè)名字陌生)等大師將Eclipse中單人持續(xù)交付的體驗(yàn)拓展到整個(gè)團(tuán)隊(duì)，使得整個(gè)團(tuán)隊(duì)在一個(gè)統(tǒng)一過(guò)程，同一平臺(tái)，統(tǒng)一計(jì)劃中，交互性的完成工作。

Rational Team Concert誕生了，它使得大規(guī)模(500人以上)工程化的軟件開(kāi)發(fā)與設(shè)計(jì)變得更加容易。一直到2012年左右，DevOps文化漸漸在市場(chǎng)中盛行起來(lái)。其實(shí)對(duì)于傳統(tǒng)軟件來(lái)講，做部署并不擅長(zhǎng)，所以這兩家巨頭都不約而同的收購(gòu)了兩個(gè)做持續(xù)交付軟件的公司：In Release和 Urban Code。于是全生命周期的協(xié)同開(kāi)發(fā)工具已經(jīng)完備，DevOps 從概念到落地都有了完整的鏈路。從兩個(gè)巨頭的軟件工程之路可以看到，DevOps的出現(xiàn)是一個(gè)漸進(jìn)的過(guò)程。它的內(nèi)生原因是人們不斷追逐軟件生產(chǎn)的工程化，產(chǎn)業(yè)成本降低以及效率的提升。 

過(guò)去20年，軟件開(kāi)發(fā)工具的發(fā)展趨勢(shì)是不斷的將軟件生命周期不同階段的工具整合起來(lái)，形成一個(gè)大而全的軟件生產(chǎn)平臺(tái)。一個(gè)企業(yè)采用單一的生命周期工具有時(shí)候會(huì)受到學(xué)習(xí)成本，遺留系統(tǒng)，集成壁壘等諸多原因的制約。而微服務(wù)化的DevOps開(kāi)發(fā)工具則幫助用戶解決這一問(wèn)題，諸多PaaS平臺(tái)上的DevOps實(shí)踐就是以微服務(wù)工具鏈的形式推出。可以說(shuō)微服務(wù)的設(shè)計(jì)方法與相關(guān)的支持工具，和DevOps這種小團(tuán)隊(duì)，持續(xù)迭代持續(xù)交付的理念簡(jiǎn)直是天作之合。

2、組織的變化

團(tuán)隊(duì)組織結(jié)構(gòu)也在這些年發(fā)生了微妙的變化。不管是全棧工程師還是流行的NoOps都在說(shuō)明專業(yè)的界限被打破，開(kāi)發(fā)團(tuán)隊(duì)由技術(shù)向業(yè)務(wù)轉(zhuǎn)型。 

對(duì)于很多測(cè)試人員來(lái)說(shuō)，這是一個(gè)憂傷的話題。很多IT公司的功能測(cè)試部門FVT已經(jīng)被開(kāi)發(fā)人員所取代。取代的基礎(chǔ)是用各種自動(dòng)化軟件，做到更好的單元測(cè)試，冒煙測(cè)試。并且在迭代的后期利用開(kāi)發(fā)人員的閑暇時(shí)間來(lái)完成手動(dòng)測(cè)試。傳統(tǒng)的測(cè)試人員需要培養(yǎng)自身承擔(dān)自動(dòng)化測(cè)試用例，性能測(cè)試用例，系統(tǒng)測(cè)試等復(fù)雜測(cè)試工作的能力。 

當(dāng)DevOps相關(guān)的平臺(tái)統(tǒng)一后，開(kāi)發(fā)驗(yàn)證階段的產(chǎn)品部署架構(gòu)，部署模式可以無(wú)縫切換到生產(chǎn)態(tài)。對(duì)于實(shí)際的生產(chǎn)態(tài)部署來(lái)說(shuō)也許就是一個(gè)環(huán)境的切換，為了確保萬(wàn)無(wú)一失，在一個(gè)準(zhǔn)生產(chǎn)系統(tǒng)之上演練上線工作。因此傳統(tǒng)的開(kāi)發(fā)和運(yùn)維人員之間的界限會(huì)越來(lái)越模糊，以及云平臺(tái)對(duì)于服務(wù)FailOver策略的處理越來(lái)越成熟。

今后的運(yùn)維團(tuán)隊(duì)可能非常的輕量級(jí)。軟件工程的大方向是被經(jīng)濟(jì)利益所驅(qū)動(dòng)的，所以DevOps運(yùn)用之后很多開(kāi)發(fā)人員也許會(huì)“被迫”去做更多測(cè)試，運(yùn)維的工作，是不是有點(diǎn)無(wú)奈?

3、軟件過(guò)程的發(fā)展

直至今天，瀑布開(kāi)發(fā)模式仍舊是許多組織采納的方式。不用質(zhì)疑，瀑布方式在中國(guó)有一定的文化基礎(chǔ)。但是漸漸的我們意識(shí)到嚴(yán)格的瀑布模式往往會(huì)造成一定的資源浪費(fèi)。比如在相同的人員和相同的時(shí)間長(zhǎng)度下，傳統(tǒng)過(guò)程交付可能花費(fèi)大量的時(shí)間去完成是一份完整的需求文檔，但是留給軟件開(kāi)發(fā)的時(shí)間少之又少，再加上需求的變化?；仡^來(lái)看需求文檔往往已經(jīng)過(guò)時(shí)。 

類似RUP(Rational Unified Process)的迭代開(kāi)發(fā)模式就是盡可能的早的獲得用戶的意見(jiàn)，控制風(fēng)險(xiǎn)。它其實(shí)是介于敏捷和瀑布之間的一種模型，不如敏捷靈活但是控制性比敏捷更強(qiáng)。RUP的迭代雖然允許需求和開(kāi)發(fā)并行，但是他仍然強(qiáng)調(diào)大部分需求內(nèi)容都應(yīng)該在主要開(kāi)發(fā)工作之前完成，而不是敏捷中代碼就是設(shè)計(jì)，需求和開(kāi)發(fā)互為彼此，不斷完善的方式。顯而易見(jiàn)敏捷需求的時(shí)間大大減少了，所以后期調(diào)整需求的代價(jià)較之瀑布和迭代來(lái)講也更低。

XP極限編程甚至不太推崇大家做過(guò)度的設(shè)計(jì)，類似于一個(gè)CRUD的功能，程序員有時(shí)會(huì)不自覺(jué)的追求更高的拓展性，搞出了一個(gè)框架來(lái)。這讓我想起來(lái)一個(gè)很有意思的問(wèn)題。那就是項(xiàng)目與產(chǎn)品的細(xì)微區(qū)別。做項(xiàng)目大多是為了追求短期利益，滿足客戶功能需求為先，良好的拓展性并不是項(xiàng)目的核心需求。不必要的設(shè)計(jì)會(huì)影響接納需求變化的能力，這和擁抱改變的想法有些不一致。類似在ThoughtWorks這種做敏捷咨詢的公司，客戶會(huì)另外付錢購(gòu)買代碼重構(gòu)的effort。而產(chǎn)品研發(fā)的需求相對(duì)固定，并且一個(gè)產(chǎn)品要有良好的發(fā)展，必須培養(yǎng)一個(gè)良好的生態(tài)系統(tǒng)，擁抱未來(lái)不同的拓展需求。長(zhǎng)期來(lái)看框架和平臺(tái)化反而符合產(chǎn)品的利益。所以敏捷中倡導(dǎo)有些原則有時(shí)要辯證的看。

敏捷方法在國(guó)內(nèi)還沒(méi)焐熱，大規(guī)模敏捷的軟件過(guò)程已經(jīng)誕生。然而在很多敏捷大師的眼中，SAFe和Less只不過(guò)是穿了馬甲的RUP。敏捷不能大規(guī)模開(kāi)展嗎?其實(shí)不是不能開(kāi)展，而是如何開(kāi)展的問(wèn)題。大家知道敏捷推崇的是小團(tuán)隊(duì)文化，類似亞馬遜倡導(dǎo)的Two-pizza團(tuán)隊(duì)，建議團(tuán)隊(duì)規(guī)模維持在7人左右。然而動(dòng)輒幾千人的跨國(guó)研發(fā)組織，如何開(kāi)展敏捷的確是一個(gè)問(wèn)題，這就是大規(guī)模敏捷存在的意義。

二、DevOps轉(zhuǎn)型陷阱

DevOps簡(jiǎn)單的來(lái)翻譯就是運(yùn)維開(kāi)發(fā)一體化。但是究竟如何來(lái)一體化，怎么做才能一體化?可能不同人對(duì)DevOps有著不同的理解，這取決于大家在哪個(gè)場(chǎng)合被什么人安利的。認(rèn)識(shí)的盲點(diǎn)也就造成了實(shí)踐的誤區(qū)。 

比如說(shuō)自動(dòng)化，基礎(chǔ)設(shè)施即編碼，配置管理數(shù)據(jù)庫(kù)的應(yīng)用，看板方法在運(yùn)維中的應(yīng)用等等，可以說(shuō)這一切都是有關(guān)DevOps的實(shí)踐，而又不是DevOps的全部。向DevOps轉(zhuǎn)型的路上有很多坑，我們先從文化轉(zhuǎn)型談起。

1、文化轉(zhuǎn)型陷阱 

很多人好奇敏捷和DevOps是什么關(guān)系。敏捷是一種軟件開(kāi)發(fā)過(guò)程，最初只是在軟件開(kāi)發(fā)中推廣，很多人提出由開(kāi)發(fā)敏捷轉(zhuǎn)型到運(yùn)維敏捷，從而到業(yè)務(wù)敏捷。這個(gè)提議毋庸置疑，不管從文化，流程以及工具層面都是很好的延伸?？梢哉f(shuō)敏捷方法，敏捷工具為DevOps理念提供了很好的理論指導(dǎo)和工具支持。近些年來(lái)很多公司逐漸開(kāi)始進(jìn)行敏捷實(shí)踐，比如說(shuō)項(xiàng)目經(jīng)理變成了Scrum主管，用戶故事替代了以前的需求，開(kāi)發(fā)計(jì)劃變成了更短的沖刺計(jì)劃。以前每周一次的組會(huì)變成了每天的站會(huì)。一開(kāi)始大家都精神滿滿，久而久之覺(jué)得每天的站會(huì)太麻煩。而Scrum主管還是以前那個(gè)逼著大家干活兒的項(xiàng)目經(jīng)理。沖刺使得開(kāi)發(fā)周期變短了，能做的功能也變少了。頻繁上線給運(yùn)維人員帶來(lái)更大的壓力，生產(chǎn)環(huán)境的Bug似乎比以前還要多。

“如果不了解團(tuán)隊(duì)自治，責(zé)任共擔(dān)，面向交付，那就不了解DevOps文化。”

2、工具轉(zhuǎn)型陷阱 

[[186121]] 

不論是之前的敏捷，還是現(xiàn)在的DevOps，很多人對(duì)于CASE工具都有一個(gè)誤區(qū)，覺(jué)得用了這個(gè)工具，就具有相應(yīng)的軟技能。但是用了一陣子之后才發(fā)現(xiàn)完全不是這回事兒。為什么會(huì)出現(xiàn)這種假象呢?

我們知道工具僅僅是現(xiàn)實(shí)工作中的一部分，如果僅僅是部署了DevOps工具，然而人員和整個(gè)工作流程并未改變會(huì)出現(xiàn)什么?很可能出現(xiàn)的情況下是，大家用共同的工具進(jìn)行工作，當(dāng)然也取得了比之前好一點(diǎn)的效果，但是工具壁壘并沒(méi)有消除。

“如果CASE工具只是孤島，那就很難幫助企業(yè)培養(yǎng)好的DevOps實(shí)踐。”

3、DevOps的雙刃劍 

[[186122]] 

其實(shí)風(fēng)險(xiǎn)本身并不可怕，可怕的是拒絕風(fēng)險(xiǎn)，或者放任風(fēng)險(xiǎn)。大家可能已經(jīng)看過(guò)很多DevOps宣傳，覺(jué)得實(shí)行DevOps之后可以做到萬(wàn)無(wú)一失，從開(kāi)發(fā)到交付是分分鐘搞定的事情。其實(shí)這里有個(gè)陷阱。那就是工具可以幫助生產(chǎn)到交付快速進(jìn)行，但是從另一個(gè)角度講，如果一旦出現(xiàn)問(wèn)題，錯(cuò)誤也可能會(huì)很快傳遞到生產(chǎn)環(huán)境中。所以如何快速捕捉問(wèn)題，解決問(wèn)題，而不是讓問(wèn)題傳遞，這才是DevOps要處理的問(wèn)題。另外盡早的在持續(xù)交付的初期發(fā)現(xiàn)問(wèn)題，比如說(shuō)有價(jià)值的缺陷，然后把它作為單元測(cè)試的目標(biāo)去防范，這對(duì)于團(tuán)隊(duì)來(lái)說(shuō)是一個(gè)不斷成長(zhǎng)的過(guò)程。

“精益的側(cè)面是控制風(fēng)險(xiǎn)，所以要小心風(fēng)險(xiǎn)和DevOps流程一起傳遞。”

三、DevOps核心實(shí)踐

剛才說(shuō)了很多DevOps轉(zhuǎn)型中的陷阱，也就是說(shuō)一不小心就會(huì)栽到坑里，覺(jué)得DevOps就是那樣了，做著挺別扭，更沒(méi)帶來(lái)什么好處。要知道DevOps實(shí)際上是一種面向軟件交付的理念。文化轉(zhuǎn)型真的挺難，到底該怎么做呢?我們從三個(gè)維度講述DevOps的核心實(shí)踐。

1、自治的小型化團(tuán)隊(duì) 

這點(diǎn)對(duì)于很多公司，特別是目前國(guó)內(nèi)的諸多公司來(lái)講也許很難做到。組織的自治意味著控制力的減弱?？刂屏Φ臏p弱加上人類天生的惰性將導(dǎo)致項(xiàng)目的失敗。這可能是團(tuán)隊(duì)轉(zhuǎn)型中存在的共同問(wèn)題。實(shí)際上自治并不是說(shuō)缺乏管理，而是說(shuō)對(duì)目標(biāo)做出正確的期望，對(duì)結(jié)果做出合理評(píng)價(jià)。中間的過(guò)程通過(guò)一系列的檢查點(diǎn)做出指導(dǎo)和糾正。其余的工作交給團(tuán)隊(duì)去協(xié)調(diào)完成。 

首先敏捷實(shí)踐中將用戶故事，任務(wù)等明確責(zé)任人，這是非常好的做法。明確了責(zé)任，大家才能向目標(biāo)邁進(jìn)。而另一個(gè)責(zé)任共擔(dān)的好辦法是讓每個(gè)人參與團(tuán)隊(duì)計(jì)劃的制定，大家?guī)椭蝿?wù)的負(fù)責(zé)人共同估算出故事點(diǎn)。這樣不僅會(huì)培養(yǎng)團(tuán)隊(duì)成員的責(zé)任感，并且最終估算的結(jié)果會(huì)比項(xiàng)目經(jīng)理自己做出的決策更加準(zhǔn)確。在項(xiàng)目執(zhí)行的時(shí)候，看板等工具的運(yùn)用使團(tuán)隊(duì)中每個(gè)參與者的工作都具有相同的可見(jiàn)性。以看板中待辦項(xiàng)以及任務(wù)狀態(tài)確定每天站會(huì)的內(nèi)容。而不是架構(gòu)師匯報(bào)技術(shù)難點(diǎn)，項(xiàng)目經(jīng)理匯報(bào)開(kāi)發(fā)狀態(tài)，大多數(shù)人被忽略的情況。 

不超過(guò)10人的小團(tuán)隊(duì)被很多企業(yè)證明是一個(gè)良好的實(shí)踐。可以讓對(duì)的人去做擅長(zhǎng)的事，如果團(tuán)隊(duì)過(guò)大很多人無(wú)法承擔(dān)合適自己的角色也是一種浪費(fèi)。另外隨著持續(xù)交付的演進(jìn)，產(chǎn)品總有新的需求，也有舊的問(wèn)題。如何合理分配人員從而做到一石二鳥(niǎo)?一些組織開(kāi)始將團(tuán)隊(duì)分為若干個(gè)特性團(tuán)隊(duì)和維護(hù)團(tuán)隊(duì)。這樣能帶來(lái)以下好處：

• 每個(gè)特性團(tuán)隊(duì)都有一個(gè)架構(gòu)師，同時(shí)也是Scrum主管。由于人數(shù)小所以很容易做到工作進(jìn)度與工作量的管理。
• 特性團(tuán)隊(duì)和維護(hù)團(tuán)隊(duì)，互相輪崗。在維護(hù)團(tuán)隊(duì)中，成員可以接觸客戶，新成員可以通過(guò)修復(fù)Bug熟悉產(chǎn)品，對(duì)產(chǎn)品足夠成熟后再輪崗到特性團(tuán)隊(duì)。
• 不同的小團(tuán)隊(duì)甚至可以不用在一個(gè)地方。
• 從DevOps的角度，一個(gè)大的產(chǎn)品團(tuán)隊(duì)就可以完成項(xiàng)目開(kāi)發(fā)到上線的整個(gè)交付工作。

2、可控的全程追溯工具

用一句之前流行的話來(lái)說(shuō)，那就是有了這么多高大上的工具之后，還是做不好DevOps。如何正確的使用DevOps工具呢?核心的概念其實(shí)就是讓我們?cè)诠ぞ呱纤龅氖虑樵诓煌纳芷跁r(shí)可以做到全鏈路的可追溯，因此我們給出以下實(shí)踐：

• 從需求出發(fā)，驅(qū)動(dòng)任務(wù)執(zhí)行。
• 任務(wù)和代碼生產(chǎn)相結(jié)合，進(jìn)行追溯。
• 以任務(wù)為單位進(jìn)行持續(xù)集成。
• 以需求為單位進(jìn)行持續(xù)交付。
• 以質(zhì)量為綱，進(jìn)行系統(tǒng)驗(yàn)收。
• 運(yùn)維規(guī)范化。
• 隨時(shí)隨地的溝通。
• 持續(xù)監(jiān)控，持續(xù)改進(jìn)。

參照上面的實(shí)踐，我們來(lái)舉個(gè)例子。開(kāi)篇我們講了兩個(gè)業(yè)界著名的DevOps支持平臺(tái)，他們是緊耦合DevOps工具。隨著開(kāi)源軟件越來(lái)越多，功能越來(lái)越強(qiáng)大，甚至某些已經(jīng)超過(guò)了商業(yè)軟件的能力。因此越來(lái)越多的公司都會(huì)基于本公司原有的開(kāi)源工具之上構(gòu)建DevOps環(huán)境。我們盡量的選取了公有云和私有云中都有的工具版本進(jìn)行說(shuō)明。

通過(guò)上面的實(shí)踐，就可以將一個(gè)DevOps平臺(tái)搭建起來(lái)了。根據(jù)用戶的需要可以在私有云和公有云的不同選擇不同的版本進(jìn)行平臺(tái)建設(shè)。只有將這些核心工件集成起來(lái)才能形成有效的可追溯鏈路。

這種集成方式給運(yùn)維帶來(lái)的改變可能要多于傳統(tǒng)的研發(fā)，因?yàn)閭鹘y(tǒng)的運(yùn)維在方法論，工具，規(guī)范程度等方面還遠(yuǎn)不及開(kāi)發(fā)，比如說(shuō)：

• 與很多成熟的開(kāi)發(fā)流程脫節(jié)，以及生產(chǎn)環(huán)境的相對(duì)隔離造成了運(yùn)維的黑賬本(碎片化的腳本)。
• 環(huán)境部署后，使用者和管理者的信息不同步造成了很多僵尸系統(tǒng)。

近些年來(lái)，基礎(chǔ)設(shè)施既編碼(IaC)以及配置管理數(shù)據(jù)庫(kù)(CMDB)的應(yīng)用實(shí)際上就是為了解決上面問(wèn)題。既然運(yùn)維實(shí)際采用一系列的腳本來(lái)部署和管理系統(tǒng)，那么就應(yīng)該把這些腳本和開(kāi)發(fā)代碼一樣統(tǒng)一化管理，甚至納入。而CMDB的作用就是將運(yùn)維的工作成果和企業(yè)的其他IT資產(chǎn)統(tǒng)一管理，消除那些僵尸系統(tǒng)。

3、實(shí)時(shí)的度量驅(qū)動(dòng) 

[[186125]] 

軟件開(kāi)發(fā)過(guò)程中充滿了各種各樣不確定的因素，有時(shí)一個(gè)小情況的出現(xiàn)就會(huì)成大程度影響軟件產(chǎn)品的按時(shí)交付。對(duì)于中高層管理者來(lái)講，只能通過(guò)重復(fù)的人工周報(bào)月報(bào)來(lái)獲取信息。然而不及時(shí)，且摻雜人工數(shù)據(jù)的報(bào)告講給決策支持帶來(lái)很大的誤導(dǎo)。DevOps就是要將數(shù)據(jù)鏈路打通，為管理者提供實(shí)時(shí)，準(zhǔn)確的生命周期數(shù)據(jù)。使管理者在風(fēng)險(xiǎn)到來(lái)之前有效的對(duì)其管控。

可能在傳統(tǒng)的印象中度量不就是一堆報(bào)表嗎?其實(shí)這里有個(gè)很大的誤區(qū)，那就是度量的方法更多的是通過(guò)數(shù)據(jù)看趨勢(shì)，事先為管理決策作出支持，而不是事后分析。比如說(shuō)項(xiàng)目經(jīng)理在看到缺陷打開(kāi)不斷呈現(xiàn)上升趨勢(shì)就應(yīng)該去尋找問(wèn)題，進(jìn)行干預(yù)。Scrum主管在看到任務(wù)周轉(zhuǎn)時(shí)間要長(zhǎng)于原先的預(yù)估時(shí)間，那就要評(píng)估原先的沖刺計(jì)劃是否能達(dá)成。實(shí)施度量正是切合敏捷的擁抱變化的理念，幫助項(xiàng)目的參與者盡早的發(fā)現(xiàn)問(wèn)題，在需要的時(shí)刻做出干預(yù)。有關(guān)于度量更多的信息，請(qǐng)參看我以往的微課堂記錄。

4、三者融合的最佳實(shí)踐 

用什么方法能將三者融合起來(lái)呢?我們發(fā)現(xiàn)使用Kanban(看板)Baseline(基線)和Pipeline(管道)這三種方法可以將任務(wù)管理，版本控制，過(guò)程管理緊密的聯(lián)系在一起。

• 看板：以任務(wù)的狀態(tài)為核心，管理在制品的生產(chǎn)情況。任務(wù)是自組織團(tuán)隊(duì)的工作契約。
• 基線：以工件的版本為核心，選取合格的交付物。比如說(shuō)開(kāi)發(fā)團(tuán)隊(duì)決定哪個(gè)代碼提交版本，或者編譯的構(gòu)建版本為最終交付的版本。度量指導(dǎo)基線的產(chǎn)生。
• 管道：以生命周期階段為核心，控制基線交付物的投產(chǎn)。比如說(shuō)一個(gè)合格的代碼基線目前處于編譯態(tài)，還是部署態(tài)。自動(dòng)化工具圍繞管道互相集成。 

那什么又是將這三者融合在一起的方法呢?答案就是工作項(xiàng)(WorkItem)。它涵蓋了需求(長(zhǎng)篇故事，特性，用戶故事)，開(kāi)發(fā)(任務(wù)，缺陷),測(cè)試(測(cè)試用例，測(cè)試計(jì)劃)等。

• 工作項(xiàng)是看板展示的最小單元，看板的泳道就是工作項(xiàng)的狀態(tài)。
• 基線是通過(guò)需求工作項(xiàng)規(guī)劃，任務(wù)工作項(xiàng)生產(chǎn)，測(cè)試工作項(xiàng)驗(yàn)收的最終產(chǎn)物。
• 工作項(xiàng)是生命周期不同交付物的容器，交付物的最終投產(chǎn)通過(guò)管道體現(xiàn)。

四、DevOps生態(tài)環(huán)境 

最近這幾年可以說(shuō)IT行業(yè)發(fā)生了一個(gè)質(zhì)的改變。不論從方法論，還是軟件工具以及基礎(chǔ)設(shè)施都讓軟件開(kāi)發(fā)這件事與業(yè)務(wù)結(jié)合的越來(lái)越緊密。可以說(shuō)DevOps就是云平臺(tái)開(kāi)發(fā)運(yùn)營(yíng)的指導(dǎo)思想。在人員角色方面，推崇全棧工程師，讓開(kāi)發(fā)者更貼近業(yè)務(wù)。在開(kāi)發(fā)方法方面，而在這個(gè)平臺(tái)之上從開(kāi)發(fā)到運(yùn)營(yíng)流轉(zhuǎn)的交付物就是以微服務(wù)方法開(kāi)發(fā)的應(yīng)用。在物理形態(tài)方面，以容器的方式交付到生產(chǎn)部門運(yùn)營(yíng)。對(duì)于使用者來(lái)講，這種業(yè)務(wù)的最終交付形態(tài)可能就是一系列的API接口，或者直接可用的應(yīng)用。一切都變得平滑起來(lái)。 

如需成為EAii架構(gòu)研究院會(huì)員加入微信群參與架構(gòu)設(shè)計(jì)與討論直播，享受微課堂PPT搶先下載等權(quán)益，請(qǐng)直接回復(fù)您的微信號(hào)至此公眾號(hào)。

關(guān)于作者：

胡帥

普元信息高級(jí)軟件架構(gòu)師，計(jì)算機(jī)軟件與理論碩士。曾供職于IBM中國(guó)開(kāi)發(fā)實(shí)驗(yàn)室，參與Rational Team Concert, Rational Insight等產(chǎn)品研發(fā)，曾經(jīng)擔(dān)任著名開(kāi)源BI產(chǎn)品BIRT社區(qū)顧問(wèn)。為工行，招行，建行，美國(guó)通用等大型企業(yè)提供DevOps以及BI產(chǎn)品咨詢實(shí)施服務(wù)。在DevOps以及BI方面積累了豐富的研發(fā)與實(shí)施經(jīng)驗(yàn)。 

[[186126]]