【51CTO.com原創(chuàng)稿件】隨著互聯(lián)網(wǎng)產(chǎn)業(yè)的飛速發(fā)展，IT 研發(fā)的工作方式也越發(fā)的靈活多變。從應(yīng)用的角度來說，由原來的單服務(wù)應(yīng)用，到現(xiàn)在的微服務(wù)應(yīng)用，處理的數(shù)據(jù)量和類型也在不斷增長(zhǎng)。

[[281102]] 

圖片來自 Pexels

從團(tuán)隊(duì)的角度來說，不僅包括開發(fā)，測(cè)試人員，還引入了運(yùn)維，安全，系統(tǒng)，網(wǎng)絡(luò)等各個(gè)專業(yè)的人員。

那么在新的時(shí)代下，我們?nèi)绾卫?DevOps(開發(fā)運(yùn)維)的方法論指導(dǎo)交付過程，就顯得尤為重要了。

我們將從 DevOps 的兩個(gè)要點(diǎn)三個(gè)原則切入，來看看組織，團(tuán)隊(duì)，流程的優(yōu)秀實(shí)踐。

DevOps 的兩個(gè)要點(diǎn)和三原則

做任何一件事情都有其價(jià)值，做事的過程就是“把業(yè)務(wù)構(gòu)想轉(zhuǎn)化為客戶價(jià)值的過程”，我們稱之為價(jià)值流。

對(duì)于研發(fā)團(tuán)隊(duì)來說，也存在技術(shù)價(jià)值流。它就是通過“開發(fā)+運(yùn)維”的敏捷迭代的方式為用戶提供價(jià)值。技術(shù)價(jià)值流就是第一個(gè)要點(diǎn)。

 

通過開發(fā)運(yùn)維的方式，幫助業(yè)務(wù)想法觸達(dá)到客戶需求

如果把我們創(chuàng)造價(jià)值流的工作分成兩個(gè)階段：

• 第一個(gè)階段是設(shè)計(jì)和開發(fā)
• 第二個(gè)階段是測(cè)試和運(yùn)維

 

技術(shù)價(jià)值流創(chuàng)造的兩個(gè)階段

那么前置時(shí)間是客戶提出需求，我們創(chuàng)建一個(gè)工單解決這個(gè)需求，然后處理工單，直到工作完成的時(shí)間的總和。前置時(shí)間作為第二個(gè)要點(diǎn)是我們值得關(guān)注的。

 

部署工作的前置時(shí)間和處理時(shí)間

通常情況下從設(shè)計(jì)，開發(fā)，測(cè)試，運(yùn)維中間需要經(jīng)歷很多復(fù)雜漫長(zhǎng)的過程。

 

交付的過程復(fù)雜且漫長(zhǎng)

我們想要達(dá)到的目標(biāo)是，在代碼版本控制中不斷提交小批量的代碼，每次提交都會(huì)做自動(dòng)化的編譯，自動(dòng)化測(cè)試，手動(dòng)測(cè)試(探索測(cè)試)，然后再部署到生產(chǎn)環(huán)境中。

為了實(shí)現(xiàn)這個(gè)目標(biāo)，需要盡量讓設(shè)計(jì)，開發(fā)，測(cè)試，發(fā)布的時(shí)間縮短，給客戶提供最大程度的技術(shù)價(jià)值流。

基于上面提到的兩個(gè)要點(diǎn)，下面三個(gè) DevOps 原則就是最好的選擇。

流動(dòng)原則

為了縮短從開發(fā)到上線之間的時(shí)間，提高服務(wù)質(zhì)量和可靠性，我們會(huì)加快開發(fā)(Dev)和運(yùn)維(Ops)之間的流動(dòng)。我們一起來看看需要注意哪些方面。

①使工作可見

和傳統(tǒng)行業(yè)相比軟件開發(fā)行業(yè)的工作可見度不高。通常只有完全做完才能看到可以使用的用戶界面，有的后臺(tái)服務(wù)甚至完成以后都看不到長(zhǎng)什么樣子。

但是對(duì)于不可見的東西，人們對(duì)其又難以掌控，所以我們需要對(duì)工作進(jìn)行可視化。

在敏捷開發(fā)中我們會(huì)對(duì)每個(gè)階段的任務(wù)進(jìn)行切割，協(xié)助項(xiàng)目推薦和軟件開發(fā)的完成。

 

開發(fā)，運(yùn)維，UAT，交付全流程

同時(shí)我們要告訴團(tuán)隊(duì)，只有軟件交付到用戶手中并且給用戶帶來價(jià)值了，我們的工作才算完成。

②限制每人同時(shí)持有的任務(wù)數(shù)

這種場(chǎng)景大家是不是經(jīng)常遇到，你在開發(fā)某一個(gè)功能的時(shí)候，測(cè)試同學(xué)向你報(bào)了一個(gè)急需解決的 Bug，同時(shí)產(chǎn)品經(jīng)理又跑過來說這個(gè)需求可能需要再改改，架構(gòu)師也找你談重構(gòu)的事情。

這導(dǎo)致一個(gè)人同時(shí)要處理很多事情，每件事情都很重要，都需要馬上完成。就好像攤大餅一樣，每個(gè)事情都做，每件事都做不好。你會(huì)不斷地被打擾，在任務(wù)之間切換，使得效率變低。

因此，需要借助看板控制每人的任務(wù)量，讓任務(wù)保持合理的數(shù)量，從而保證質(zhì)量和效率。

 

一人持有多個(gè)任務(wù)

③減少批量大小

我們?cè)陂_發(fā)過程中經(jīng)常會(huì)遇到這種情況，一個(gè)事情有四個(gè)步驟組成，我們需要完成 100 件這樣的事情。

于是，根據(jù)抽象和分工合作的原則，我們把這個(gè)事情分成 4 步，每個(gè)步驟分配給一個(gè)人來完成，這樣每個(gè)人完成每個(gè)步驟 100 次這個(gè)事情就完成了。

這個(gè)方法沒有錯(cuò)，但是在做這個(gè)事情的初期，最好是把這個(gè)事情的四個(gè)步驟由一個(gè)人先完成一次，看看是否存在潛在的問題，在看看在完成過程中是否有可以總結(jié)的經(jīng)驗(yàn)和需要踩的坑。

這樣往復(fù)幾次，把一些問題解決以后再找其他幾個(gè)人來分步驟幫忙。這種方式在快速試錯(cuò)的互聯(lián)網(wǎng)企業(yè)用的非常的多。

 

先完成閉環(huán)流程，再?gòu)?fù)制經(jīng)驗(yàn)

④減少交接次數(shù)

我們?cè)谕瓿梢粋€(gè)事情的時(shí)候往往會(huì)和其他的團(tuán)隊(duì)和人員進(jìn)行大量的溝通，請(qǐng)求，委派，通知，協(xié)調(diào)等工作。

例如：軟件發(fā)布過程中就需要面臨功能測(cè)試，集成測(cè)試，環(huán)境搭建，配置服務(wù)器，存儲(chǔ)管理，網(wǎng)絡(luò)等工作。如果任何事情都需要審核，協(xié)調(diào)勢(shì)必會(huì)降低工作的效率。

這里互聯(lián)網(wǎng)企業(yè)的扁平化管理就可以借鑒，每個(gè)小隊(duì)包括技術(shù)，業(yè)務(wù)，管理和不同領(lǐng)域的人員，這樣減少了跨部門的溝通，工作效率更高。

 

減少交接

⑤識(shí)別和改善約束點(diǎn)

在軟件開發(fā)交付的過程中有很多約束，包括：人員，時(shí)間，軟件，服務(wù)器，網(wǎng)絡(luò)等等。

在 DevOps 中也一樣，我們需要不斷的識(shí)別這個(gè)約束，并且不斷改善這些限制條件才能推進(jìn)整個(gè)開發(fā)的進(jìn)度。

 

讓約束點(diǎn)之間能夠平滑過度

環(huán)境搭建：建議使用自動(dòng)的環(huán)境部署，利用現(xiàn)在容器技術(shù)(Docker)提高整個(gè)環(huán)境的搭建速度。

代碼部署：建議讓代碼上傳，編譯，部署自動(dòng)化起來。這些動(dòng)作在一個(gè)軟件交付團(tuán)隊(duì)每天都在不斷的上演，開發(fā)團(tuán)隊(duì)的人越多這個(gè)工作更是需要做。

測(cè)試執(zhí)行：這個(gè)是承接上一點(diǎn)的，一旦一個(gè)軟件發(fā)布以后就需要跟進(jìn)自動(dòng)化的測(cè)試。

至少用自動(dòng)化腳本針對(duì)核心 20% 的功能進(jìn)行測(cè)試，然后再由測(cè)試人員對(duì)具體功能進(jìn)行冒煙測(cè)試。

軟件隨著功能擴(kuò)展，測(cè)試工作量也會(huì)隨之增大。如果不用自動(dòng)化測(cè)試，依靠手動(dòng)測(cè)試工作量是很大的。

解耦架構(gòu)：隨著微服務(wù)的風(fēng)行，現(xiàn)在基本都是組件式的設(shè)計(jì)，組件出現(xiàn)問題都做故障隔離和熔斷機(jī)制，那么也需要針對(duì)組件進(jìn)行發(fā)布。

反饋原則

如果說流動(dòng)原則說的是，從開發(fā)到運(yùn)維的快速流動(dòng)，那么反饋原則就是從運(yùn)維到開發(fā)快速的反饋。這兩個(gè)原則周而復(fù)始運(yùn)轉(zhuǎn)，才能為客戶交付最好最快的軟件服務(wù)。

①及時(shí)發(fā)現(xiàn)問題

一個(gè)服務(wù)/產(chǎn)品的交付歷經(jīng)了很多個(gè)過程，從需求分析，原型設(shè)計(jì)，架構(gòu)設(shè)計(jì)，編碼，測(cè)試，發(fā)布，集成測(cè)試，驗(yàn)收測(cè)試，一直到上線。

每個(gè)階段都有工作者參與其中。任何一個(gè)問題的產(chǎn)生都是有原因的，即使不能阻止問題的產(chǎn)生，但可以第一時(shí)間發(fā)現(xiàn)問題，讓問題暴露出來。

例如：產(chǎn)品經(jīng)理沒有分析透徹，到了開發(fā)的時(shí)候就會(huì)遇到需求不清的問題，這時(shí)程序員就可以提出問題，產(chǎn)品經(jīng)理就需要對(duì)需求進(jìn)行澄清。

 

發(fā)現(xiàn)問題，反饋問題，解決問題流程圖

②解決分析問題

有這樣一種情況，在開發(fā)的時(shí)候發(fā)現(xiàn)的問題，在需求和設(shè)計(jì)上都沒有提到。如果放任錯(cuò)誤不管顯然會(huì)影響系統(tǒng)運(yùn)行。

如果采取事不關(guān)己高高掛起的態(tài)度，那么問題永遠(yuǎn)無法發(fā)現(xiàn)，那么出現(xiàn)問題我們應(yīng)該如何處理。

第一，上游環(huán)節(jié)出現(xiàn)問題，一定不要把問題帶到下游環(huán)節(jié)。在上游環(huán)節(jié)就把問題解決掉。

 

上游環(huán)節(jié)出現(xiàn)問題

第二，暫停上游環(huán)節(jié)的工作，避免新的問題繼續(xù)產(chǎn)生。

 

發(fā)現(xiàn)問題及時(shí)處理

第三，建立 PDCA 環(huán)，計(jì)劃(Plan)，實(shí)施(Do)，檢查(Check)，改進(jìn)(Action)避免此類問題不再發(fā)生。

 

建立 PDCA 機(jī)制

③源頭保證質(zhì)量

什么是源頭，相對(duì)下游來說上游就是源頭。產(chǎn)品經(jīng)理是開發(fā)的源頭，需求質(zhì)量不過關(guān)代碼就受影響。

程序員是測(cè)試人員的源頭，程序質(zhì)量有問題測(cè)試就會(huì)受影響;測(cè)試人員是客戶的源頭，如果問題都被放過了，那么就不能給客戶帶來價(jià)值。

所以，保證源頭就是保證交付的質(zhì)量。對(duì)每個(gè)過程和階段做監(jiān)控是我們要關(guān)注的：

• 需求階段：需求評(píng)審，需求確認(rèn)，需求宣講。
• 開發(fā)階段：代碼審核，結(jié)對(duì)編程，單元測(cè)試。
• 測(cè)試階段：冒煙測(cè)試，回歸測(cè)試，驗(yàn)收測(cè)試。
• 發(fā)布階段：自動(dòng)配置，自動(dòng)部署，自動(dòng)檢測(cè)。

 

追根溯源圖

④客戶同理心

客戶分為兩種，內(nèi)部客戶和外部客戶。外部客戶是通常意義的客戶，我們?yōu)榭蛻籼峁┸浖桓叮瑵M足客戶的需求，為客戶創(chuàng)造價(jià)值。

內(nèi)部客戶就是我們的下游。產(chǎn)品經(jīng)理把開發(fā)人員作為客戶，開發(fā)人員把測(cè)試人員作為客戶。

我們?cè)谧鋈魏蝿?dòng)作，發(fā)現(xiàn)任何問題，做任何決定的時(shí)候都要想想我們的“客戶”，是否對(duì)他們有利。我們要把自己放在客戶的角度來看問題，好多問題在當(dāng)下就會(huì)被解決。

 

客戶在哪里，站在客戶的角度

學(xué)習(xí)原則

學(xué)習(xí)原則是對(duì)前面兩個(gè)原則的支持，是基礎(chǔ)原則。不管你在工作中踩了多少坑，不管你在編碼過程中遭受多少失敗都不要忘記學(xué)習(xí)，持續(xù)的學(xué)習(xí)讓一個(gè)人變得更加強(qiáng)大，讓一個(gè)團(tuán)隊(duì)逐漸成熟。

①建立學(xué)習(xí)型的組織結(jié)構(gòu)

在服務(wù)交付的過程中，無論我們?nèi)绾蔚男⌒亩紵o法避免犯錯(cuò)。大家都有背鍋的經(jīng)歷。

比如某某需求，本來產(chǎn)品經(jīng)理就沒有說清楚，程序員在實(shí)現(xiàn)的時(shí)候忽略了，到了交付的時(shí)候就是程序員的鍋，之后項(xiàng)目經(jīng)理就會(huì)信誓旦旦地把開發(fā)人員批評(píng)一通。

這種場(chǎng)景在我早期工作的時(shí)候經(jīng)常遇到。后來隨著帶的項(xiàng)目越來越多，發(fā)現(xiàn)這樣“責(zé)備”式的解決問題方式是不對(duì)的。

我們應(yīng)該多從問題本身出發(fā)，找出問題的原因。總結(jié)歸納，定義好的流程和機(jī)制讓兄弟們不再犯類似的錯(cuò)誤。

如果我們把組織分為三類的話，我希望我們應(yīng)該是生機(jī)型(學(xué)習(xí)型)的組織。

 

組織類型分類

病態(tài)型：組織中的成員感到大量的恐懼和威脅(生怕做錯(cuò)事情)。大家為了保全自己都不愿承擔(dān)責(zé)任，甚至隱瞞真相和事實(shí)。

官僚型：規(guī)則多，流程僵化，大家自掃門前雪。

生機(jī)型(學(xué)習(xí)型)：在錯(cuò)誤中不斷總結(jié)，不斷學(xué)習(xí)，不斷進(jìn)步。大家積極探索，勇于承擔(dān)，樂于共享。

 

生機(jī)型組織是我們的目標(biāo)

②日常工作制度化

這里的制度化并不是為了官僚而給大家加入的繁文縟節(jié)，正好相反這些制度的產(chǎn)生都是兄弟們?cè)诠ぷ髦锌偨Y(jié)出來的經(jīng)驗(yàn)教訓(xùn)，轉(zhuǎn)換成制度的原因是希望不要有其他的兄弟再踩這些坑。

舉個(gè)例子，早先我們做發(fā)布的時(shí)候總是忘記發(fā)布數(shù)據(jù)庫的腳本，導(dǎo)致生產(chǎn)環(huán)境的程序 Run 不起來。后來，我們把更新數(shù)據(jù)庫腳本作為發(fā)布前必須做的事情寫入到發(fā)布制度中。

再后來，作為自動(dòng)化腳本寫到自動(dòng)化發(fā)布中。實(shí)際上在工作中有很多好的經(jīng)驗(yàn)，如果我們留心都可以建立這樣持續(xù)改進(jìn)的機(jī)制，成為心照不宣的制度。實(shí)際上我們?cè)谄綍r(shí)編碼中有很多事情都可以好好總結(jié)。

比如：編碼規(guī)范，命名規(guī)范，標(biāo)準(zhǔn)的 MVP/MVC/MVVM 寫法，發(fā)布流程，測(cè)試用例，測(cè)試腳本。

 

制度服務(wù)于流程

③局部經(jīng)驗(yàn)全局化

在開發(fā)/運(yùn)維過程中我們經(jīng)常會(huì)遇到各種各樣的事件(坑)，這些事件或是迎刃而解或者困擾我們?cè)S久。

但最終解決以后，我們希望把這些經(jīng)驗(yàn)放到知識(shí)庫中保存起來，這是我們共同經(jīng)歷的一筆財(cái)富。

實(shí)際上一個(gè)項(xiàng)目做完以后，問問自己你在這個(gè)項(xiàng)目里面學(xué)到了什么，就是這些經(jīng)驗(yàn)的積累。

當(dāng)你找下一份工作的時(shí)候，面試官問你遇到最困難的問題是什么的時(shí)候，你就可以自豪的分享這些經(jīng)歷了。

就算是再小的經(jīng)驗(yàn)，在放到全局的時(shí)候?qū)ζ渌募夹g(shù)人員甚至是跨部門的技術(shù)人員都是有啟發(fā)和幫助的。

 

用知識(shí)庫管理經(jīng)驗(yàn)

④注入彈性模式

這里說的彈性有兩個(gè)方面的意思，一個(gè)是指人員的彈性，一個(gè)是指我們維護(hù)系統(tǒng)的彈性。

人員的彈性，在沖刺項(xiàng)目的時(shí)候要有長(zhǎng)征的韌性和搶渡大渡河的勇氣。在項(xiàng)目不忙的時(shí)候，也需要不斷總結(jié)，學(xué)習(xí)新知識(shí)，每個(gè)人的成長(zhǎng)才能帶動(dòng)整個(gè)團(tuán)隊(duì)的成長(zhǎng)。

項(xiàng)目的彈性，用壓力測(cè)試的方法，對(duì)維護(hù)的系統(tǒng)進(jìn)行正壓力測(cè)試和負(fù)壓力測(cè)試，探查我們系統(tǒng)的承受極點(diǎn)，從而完善他。

 

團(tuán)隊(duì)彈性和系統(tǒng)彈性

DevOps 組織結(jié)構(gòu)

根據(jù)康威定律，軟件的架構(gòu)和軟件團(tuán)隊(duì)的結(jié)構(gòu)是一致的，這個(gè)是康威定律對(duì)團(tuán)隊(duì)和架構(gòu)的解讀。

我經(jīng)歷過團(tuán)隊(duì)從小到大的發(fā)展，在初期人較少時(shí)，工作流程概念不強(qiáng)，一個(gè)人做多個(gè)角色的事情，基本沒有溝通成本，軟件的架構(gòu)基本是單應(yīng)用。

后來隨著開發(fā)，測(cè)試，運(yùn)維人員的增加，總體需要處理的工作量也大了。為了方便管理和項(xiàng)目推進(jìn)效率，會(huì)對(duì)人和事情進(jìn)行切割，規(guī)定流程以及團(tuán)隊(duì)之間的溝通方式。

架構(gòu)也從原來的單應(yīng)用轉(zhuǎn)變成了后來的微服務(wù)，數(shù)據(jù)庫從原來的單庫轉(zhuǎn)化為分表分庫的模式。

 

組織結(jié)構(gòu)決定軟件架構(gòu)

開發(fā)，測(cè)試，運(yùn)維相互融合

在開發(fā)過程中，開發(fā)，測(cè)試，運(yùn)維所屬不同的專業(yè)，在項(xiàng)目推進(jìn)過程中各司其職。在 DevOps 的組織結(jié)構(gòu)中，需要他們?nèi)呋ハ嗳诤稀?/p>

開發(fā)完成以后需要通過單元測(cè)試，結(jié)對(duì)編程的方式保證代碼的質(zhì)量。測(cè)試需要發(fā)現(xiàn)/驗(yàn)證 Bug，并且與運(yùn)維合作完成壓力測(cè)試/性能測(cè)試。

大家會(huì)發(fā)現(xiàn)，現(xiàn)在很多大廠的一線運(yùn)維人員都是來自開發(fā)團(tuán)隊(duì)，甚至有很多公司都鼓勵(lì)，開發(fā)，測(cè)試人員參與運(yùn)維工作。讓他們感受一下自己的工作對(duì)下游工作的影響。

 

開發(fā)，運(yùn)維，測(cè)試相互融合

DevOps 團(tuán)隊(duì)搭建

 

團(tuán)隊(duì)成員互為依托

既然了解了 DevOps 的組織結(jié)構(gòu)，那么團(tuán)隊(duì)需要哪些成員參與呢?

• 產(chǎn)品負(fù)責(zé)人：業(yè)務(wù)方面的代表，可以把他想象成客戶。
• 開發(fā)團(tuán)隊(duì)：負(fù)責(zé)具體功能開發(fā)。
• QA 團(tuán)隊(duì)：負(fù)責(zé)質(zhì)量保障。
• 運(yùn)維團(tuán)隊(duì)：維護(hù)生產(chǎn)環(huán)境，配置，發(fā)布。
• 信息安全團(tuán)隊(duì)：負(fù)責(zé)系統(tǒng)和信息的安全。

當(dāng)然，大家可以根據(jù)自己公司的需要在這個(gè)基礎(chǔ)上增加一些管理和支持職責(zé)的團(tuán)隊(duì)。

對(duì)初創(chuàng)企業(yè)來說，如果沒有運(yùn)維和信息安全的團(tuán)隊(duì)，建議找開發(fā)團(tuán)隊(duì)的兄弟兼任。

團(tuán)隊(duì)價(jià)值流

多個(gè)團(tuán)隊(duì)合作工作，存在溝通，統(tǒng)一認(rèn)知等方面的問題。價(jià)值流圖就是為了統(tǒng)一大家的思想，讓每個(gè)團(tuán)隊(duì)的成員都知道，在什么階段需要做什么事情。實(shí)際這些圖在之前的文章中也有介紹，無非是把團(tuán)隊(duì)和階段對(duì)應(yīng)上。

 

團(tuán)隊(duì)價(jià)值流圖

工作在線

如果說要讓團(tuán)隊(duì)站在同一個(gè)平面上面，使用高效的工具是必不可少的。例如：Confluence，石墨文檔，Jira，禪道，ProcessOn，Jenkins，Bamboo，Git，JMeter，LoadRunner。

它們可以幫助我們從設(shè)計(jì)，開發(fā)，測(cè)試，發(fā)布各個(gè)階段提升工作效率。讓團(tuán)隊(duì)保持高度統(tǒng)一，讓所有的工作都在線。

 

讓工具為團(tuán)隊(duì)服務(wù)，讓工作在線

DevOps 流水線部署

團(tuán)隊(duì)存在的目的是，為了客戶創(chuàng)造價(jià)值。那么將軟件交付到用戶手中的過程，就好像工廠的流水線一樣，流水線的上游是原料，經(jīng)過加工以后，輸出的是商品。作為 DevOps 的流水線部署，需要使這個(gè)過程自動(dòng)化。

作為交付團(tuán)隊(duì)每次完成代碼編寫完成，都需要提交版本庫。提交以后，版本庫會(huì)對(duì)整體的代碼進(jìn)行編譯(構(gòu)建/Build)，并且執(zhí)行單元測(cè)試的代碼。

如果失敗，會(huì)把錯(cuò)誤信息打回交付團(tuán)隊(duì)，程序員在修正錯(cuò)誤以后再次提交代碼。只有通過后，才發(fā)布到測(cè)試環(huán)境，進(jìn)行自動(dòng)化腳本的測(cè)試。

同樣沒有通過自動(dòng)化測(cè)試，依舊會(huì)打回到開發(fā)團(tuán)隊(duì)，再次進(jìn)行修改。這個(gè)過程周而復(fù)始，直到通過用戶驗(yàn)收測(cè)試，并且發(fā)布。

 

DevOps 流水線

提交階段：是從技術(shù)角度上判斷系統(tǒng)是可以工作的。這個(gè)階段會(huì)進(jìn)行編譯，運(yùn)行單元測(cè)試腳本，通常這些腳本都是程序員自己編寫的。

另外，會(huì)針對(duì)具體代碼，由經(jīng)驗(yàn)豐富的程序員做代碼走查，或者代碼互查。這里可以使用 Junit 單元測(cè)試工具。

自動(dòng)化驗(yàn)收測(cè)試階段：是從功能和非功能角度上斷言整個(gè)系統(tǒng)是可以工作的，即從系統(tǒng)行為上看，它滿足用戶的需要并且符合客戶的需求規(guī)范。

手工測(cè)試階段：用于判斷系統(tǒng)是可用的，滿足了它的系統(tǒng)要求，試圖發(fā)現(xiàn)那些自動(dòng)化測(cè)試未能捕獲的缺陷，這部分測(cè)試內(nèi)容較為復(fù)雜，步驟較多，甚至存在多系統(tǒng)切換的情況。

這一階段通常包括探索性測(cè)試、集成環(huán)境上的測(cè)試以及 UAT(User Acceptance Testing，用戶驗(yàn)收測(cè)試)。測(cè)試人員會(huì)根據(jù) UAT 的用例對(duì)系統(tǒng)進(jìn)行測(cè)試。

發(fā)布階段：旨在將軟件交付給用戶，是直接將其應(yīng)用部署到生產(chǎn)環(huán)境，部署之后就進(jìn)入運(yùn)維階段。

按照流水線部署的好處就是，控制每個(gè)階段的交付質(zhì)量，逐步建立交付者的信心，通過層層篩選將問題擋在外面。

同時(shí)對(duì)于開發(fā)，測(cè)試，運(yùn)維人員也是考驗(yàn)。他們需要大量的協(xié)同工作，不斷地讓應(yīng)用在流水線上流動(dòng)，并且及時(shí)反饋給不同位置上的隊(duì)員。

在熟悉了流水線上的幾個(gè)階段以后，再來看看每個(gè)階段產(chǎn)生了哪些數(shù)據(jù)，以及這些數(shù)據(jù)是如何流動(dòng)的。

①流程的起點(diǎn)是，開發(fā)人員向代碼庫提交代碼。在 Checkin 代碼之前，開發(fā)人員需要把代碼庫中相關(guān)的代碼和組件下載到本地，保證修改后的代碼在本地是可以編譯通過的。

比較規(guī)范的公司，是需要申請(qǐng) Code Review，讓其他的同事走查代碼。雖然在 Checkin 到代碼庫之后，平臺(tái)會(huì)自動(dòng)運(yùn)行單元測(cè)試。但是建議各位，先做單元測(cè)試。

因?yàn)椋坏┻M(jìn)入驗(yàn)收階段，編譯會(huì)花費(fèi)大量的時(shí)間，如果出現(xiàn)問題，系統(tǒng)會(huì)生成錯(cuò)誤報(bào)告并且發(fā)給 Team Leader 或者項(xiàng)目組。

如果那個(gè)時(shí)候再改代碼，恐怕所有人都知道 Bug 是從你這里出來的了。因此，還是先在本地跑一下單元測(cè)試。

其范圍包括你修改代碼的模塊，也包括其他模塊。實(shí)際上，任何對(duì)代碼的修改都有可能影響其他模塊，即使你并沒有修改其他模塊。

持續(xù)集成管理系統(tǒng)對(duì)這次代碼提交作出響應(yīng)，從指定的代碼庫拉取代碼，并且進(jìn)行編譯，運(yùn)行單元測(cè)試，執(zhí)行代碼分析，組裝打包。

如果單元測(cè)試都通過，并且代碼符合編碼標(biāo)準(zhǔn)，就可以打包成可執(zhí)行文件，并放到一個(gè)成品庫(artifact repository)中。

當(dāng)下的持續(xù)集成服務(wù)器，都提供這些功能，并讓用戶和流水線的后續(xù)階段能以簡(jiǎn)便的方式進(jìn)行。

另外，還有像 Nexus 和 Artifactory 這樣的工具可幫助管理過程產(chǎn)物。目前比較成熟的產(chǎn)品。例如 Bamboo，Jenkins 都可以通過配置代碼庫，成品庫，通過腳本命令的方式完成上述操作。

②第二個(gè)階段通常由運(yùn)行時(shí)間較長(zhǎng)的自動(dòng)化驗(yàn)收測(cè)試。這些測(cè)試的主要內(nèi)容，是針對(duì)一些 API 和模塊的測(cè)試。

也有的項(xiàng)目組用來做頁面的測(cè)試，但是個(gè)人不建議做頁面的自動(dòng)化，特別是在頁面設(shè)計(jì)的初期，頁面元素經(jīng)常變動(dòng)，自動(dòng)化的腳本變化也很大，效果不是很好。

在此之后，部署流水線可能會(huì)有分支出現(xiàn)，這樣就可以將該構(gòu)建版本獨(dú)立部署到多個(gè)不同的環(huán)境中，比如部署到用戶驗(yàn)收測(cè)試環(huán)境、容量測(cè)試環(huán)境和生產(chǎn)環(huán)境。

也有串行的例子，比如 DEV(開發(fā))環(huán)境，INT(集成測(cè)試)環(huán)境，MO(準(zhǔn)生成)環(huán)境，Prod(生產(chǎn))環(huán)境。

通常情況下，我們希望測(cè)試人員或運(yùn)維人員可以做到自服務(wù)，即自己手工選擇需要的某個(gè)版本。

例如：可以通過 Bamboo 或者 Jenkins 工具選擇成品庫中的應(yīng)用版本，然后發(fā)布到指定的環(huán)境。

所謂的自動(dòng)化部署腳本也就是一行能夠在服務(wù)器上運(yùn)行的命令，執(zhí)行命令完成部署工作。

測(cè)試人員應(yīng)當(dāng)能夠看到需要手工測(cè)試的所有構(gòu)建版本，以及它們的狀態(tài)，之后單擊一個(gè)按鈕，運(yùn)行相應(yīng)的部署腳本將選定的構(gòu)建版本部署到選定的環(huán)境上。

 

提交和驗(yàn)收階段

總結(jié)

DevOps 模式需要遵循三個(gè)原則，快速流動(dòng)，及時(shí)反饋，堅(jiān)持學(xué)習(xí)。因此，DevOps 的組織結(jié)構(gòu)需要開發(fā)，測(cè)試，運(yùn)維緊密合作。

按照這個(gè)標(biāo)準(zhǔn)去打造團(tuán)隊(duì)，讓團(tuán)隊(duì)產(chǎn)生價(jià)值流，通過工作在線的方式，給用戶提供價(jià)值。

DevOps 的價(jià)值體現(xiàn)在流水線的部署方式，這里需要合理配置提交，驗(yàn)收，手工測(cè)試和發(fā)布階段。讓應(yīng)用快速流轉(zhuǎn)，讓團(tuán)隊(duì)收獲及時(shí)反饋，從而穩(wěn)步推進(jìn)軟件交付。

作者：崔皓

簡(jiǎn)介：十六年開發(fā)和架構(gòu)經(jīng)驗(yàn)，曾擔(dān)任過惠普武漢交付中心技術(shù)專家，需求分析師，項(xiàng)目經(jīng)理，后在創(chuàng)業(yè)公司擔(dān)任技術(shù)/產(chǎn)品經(jīng)理。善于學(xué)習(xí)，樂于分享。目前專注于技術(shù)架構(gòu)與研發(fā)管理。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】