本篇文章來(lái)自于HPE和msup共同舉辦的技術(shù)開(kāi)放日HPE測(cè)試技術(shù)總監(jiān)肖俊的分享拱绑，由壹佰案例整理編輯综芥。
一、DevOps含義解析
這是DevOps的趨勢(shì)圖猎拨。DevOps這個(gè)概念大概是在2009年被提出來(lái)的毫痕，2010年有一些公司開(kāi)始試點(diǎn)，之后DevOps的熱度持續(xù)增加迟几，這是我們?cè)诠雀杷阉鱀evOps關(guān)鍵字得到的搜索量消请，這條曲線表示了DevOps熱度呈指數(shù)級(jí)增長(zhǎng)。因此我預(yù)計(jì)2016年DevOps仍然會(huì)成為一個(gè)非常受關(guān)注的技術(shù)类腮。
什么是DevOps臊泰？
我們?cè)谠圏c(diǎn)DevOps的時(shí)候做了很多研究蚜枢，也在網(wǎng)上做了很多搜索厂抽。比較普遍的說(shuō)法是：DevOps是一種文化需频，用以打破開(kāi)發(fā)、運(yùn)維以及測(cè)試之間的工作壁壘昭殉。之所以會(huì)有壁壘是因?yàn)殚_(kāi)發(fā)、測(cè)試挪丢、運(yùn)維的工作職責(zé)蹂风、目的存在不一致性。比如開(kāi)發(fā)的主要目的是趕緊實(shí)現(xiàn)業(yè)務(wù)級(jí)的新需求及功能惠啄，交給客戶使用任内，然后根據(jù)反饋信息繼續(xù)更新死嗦；運(yùn)維的主要目的是生產(chǎn)必須快速、不能出問(wèn)題越走，所以他們不是很喜歡“變化”廊敌，因?yàn)樽兓赡軙?huì)帶來(lái)風(fēng)險(xiǎn)，隨之而來(lái)的就是各種問(wèn)題锅纺，這是他們最不愿意看到的肋殴。
如果站在他們各自的角度來(lái)看护锤，這些考慮都很正確，但現(xiàn)在的市場(chǎng)要求所有研發(fā)人員的最終目的都是“幫助業(yè)務(wù)部門(mén)創(chuàng)造商業(yè)價(jià)值”驱入，而不只是狹隘地滿足各自的目標(biāo)亏较。如何創(chuàng)造商業(yè)價(jià)值掩缓？充分滿足客戶的需求你辣〕局矗客戶的需求是多變的，而且變化的速度很快蠢熄，這就要求我們必須跟上他們的步伐签孔，快速實(shí)現(xiàn)最新功能并交給客戶使用，如果一個(gè)系統(tǒng)很穩(wěn)定但沒(méi)有人使用图仓，那它一樣不能給我們帶來(lái)任何東西救崔。
維基百科上對(duì)DevOps的解釋是：軟件開(kāi)發(fā)人員和IT運(yùn)維技術(shù)人員之間溝通合作的文化捏顺、趨勢(shì)或?qū)嵺`幅骄。透過(guò)自動(dòng)化（軟件繳付）的流程拆座，來(lái)使得構(gòu)建、測(cè)試孕索、發(fā)布軟件能夠更加地快捷躏碳、頻繁和可靠唐断。之前開(kāi)發(fā)、測(cè)試恳啥、運(yùn)維三者之間可能是獨(dú)立的钝的，現(xiàn)在要求更緊密一點(diǎn)。一句話總結(jié)沿猜，DevOps就是：開(kāi)發(fā)測(cè)（試）（運(yùn)）維融一體碗脊，敏捷高效自動(dòng)化衙伶。這也是我們對(duì)DevOps的定義和理解矢劲。
自2009年提出DevOps的概念起，很多公司都開(kāi)始實(shí)施DevOps躺同，國(guó)外比較著名的有Google笋籽、Facebook等椭员，國(guó)內(nèi)著名的有百度隘击、華為、阿里州叠、Flickr等咧栗，他們實(shí)施DevOps的結(jié)果是每天有10次部署虱肄，這是非常了不起的咏窿。
二、HPE IT在DevOps上的實(shí)踐
HPE IT部門(mén)在2014年年底的時(shí)候引入DevOps概念萝挤，2015年找了一些內(nèi)部的敏捷項(xiàng)目做試點(diǎn)怜珍，2016年我們開(kāi)始在400多個(gè)應(yīng)用里推廣DevOps。
1、引入DevOps的實(shí)際背景
既然要實(shí)踐要推廣揭璃，我們看一下目前的現(xiàn)狀瘦馍。IT在開(kāi)發(fā)的流程上使用敏捷已經(jīng)很久了应役，所以可以看到箩祥，開(kāi)發(fā)實(shí)際上采用了敏捷的迭代方法袍祖，每個(gè)沖刺都會(huì)產(chǎn)出一個(gè)可發(fā)布的產(chǎn)品。到了運(yùn)維這邊捐凭，我們不得不遵循企業(yè)發(fā)布規(guī)則：每三個(gè)月一次發(fā)布窗口茁肠，我們就必須等待缩举。根據(jù)應(yīng)用的技術(shù)不同仅孩，有不同的運(yùn)維團(tuán)隊(duì)來(lái)幫助你做生產(chǎn)環(huán)境的部署和監(jiān)控，所以我們得找到相應(yīng)的運(yùn)維團(tuán)隊(duì)站刑，提前7天提交一個(gè)rfc绞旅。這些流程做完之后，運(yùn)維團(tuán)隊(duì)開(kāi)始部署堕汞，這時(shí)要寫(xiě)一個(gè)“部署文檔”告訴他怎么上傳到服務(wù)器讯检，把哪個(gè)文件刪掉卫旱、哪個(gè)文件備份等顾翼，我看到最大的可能有十幾頁(yè)，很多時(shí)候運(yùn)維人員要管很多項(xiàng)目灸芳，部署又有問(wèn)題烙样。整個(gè)流程非常繁瑣蕊肥，敏捷在實(shí)現(xiàn)在開(kāi)發(fā)中的運(yùn)用壁却，但在運(yùn)維中仍然不足儒洛。最后我們看到“部署”變成最后一公里，最后一公里如果沒(méi)法做到“敏捷”的話卦停，前面的“敏捷”可能就白做了惊完。
2处硬、DevOps持續(xù)交付、持續(xù)部署
為了解決這些問(wèn)題件豌，我們提出了一個(gè)DevOps的方案茧彤，通過(guò)持續(xù)交付和持續(xù)部署來(lái)實(shí)現(xiàn)疆栏。持續(xù)交付和持續(xù)部署大體上包括了4個(gè)部分：1.開(kāi)發(fā)和開(kāi)發(fā)相關(guān)的壁顶；2.QA測(cè)試相關(guān)若专；3.用戶測(cè)試相關(guān)；4.生產(chǎn)運(yùn)維相關(guān)蛔糯。通過(guò)整個(gè)的DevOps持續(xù)集成、持續(xù)交付把開(kāi)發(fā)萝喘、測(cè)試琼懊、運(yùn)維三者都包括其中哼丈。
開(kāi)發(fā)環(huán)節(jié)的持續(xù)集成
我們強(qiáng)調(diào)每一個(gè)開(kāi)發(fā)人員做的任何修改醉旦，必須得在本地通過(guò)新功能的單元測(cè)試。通過(guò)了新功能的單元測(cè)試后會(huì)做整合檬输，然后提交到代碼倉(cāng)庫(kù)丧慈，一旦提交代碼到代碼倉(cāng)庫(kù)逃默，我們的服務(wù)器會(huì)自動(dòng)觸發(fā)，做自動(dòng)化構(gòu)建和比較全面的單元測(cè)試昼浦，然后再做部署到itg上面关噪，如果這個(gè)新的代碼通過(guò)了itg的測(cè)試就會(huì)顯示時(shí)綠色的使兔，沒(méi)通過(guò)會(huì)顯示是紅色的虐沥。
有的時(shí)候開(kāi)發(fā)很著急泽艘，不斷寫(xiě)新代碼希望做得快一些匹涮，不注意細(xì)節(jié)然低，QA就覺(jué)得很難理解，有的時(shí)候甚至構(gòu)建不起來(lái)带兜，提交過(guò)來(lái)也沒(méi)辦法部署刚照。舉個(gè)例子无畔，我們要求所有代碼都是小寫(xiě)繁莹，有一次我們的開(kāi)發(fā)用了第三方的一些庫(kù)文件咨演，而這個(gè)第三方的庫(kù)文件中間會(huì)有大寫(xiě)的字母，這些大寫(xiě)的字母出現(xiàn)在配置文件中拍嵌，到部署時(shí)就可能導(dǎo)致QA環(huán)境出錯(cuò)循诉。因?yàn)槲覀兊腝A環(huán)境是Liunx的系統(tǒng)茄猫，對(duì)大小寫(xiě)比較敏感划纽。
開(kāi)發(fā)經(jīng)常說(shuō)：“在我這邊是好的勇劣，是你的問(wèn)題，不是我的問(wèn)題幻捏〈劬牛”為了避免這樣的狀況出現(xiàn)瓮下，我們要求必須得在itg上做測(cè)試，這個(gè)itg和生產(chǎn)環(huán)境比較類似锭魔，都是Liunx迷捧。
代碼分支策略：?jiǎn)畏种ЫY(jié)構(gòu)
接下來(lái)介紹一個(gè)我們的分支策略漠秋。我們的代碼分支策略叫單分支結(jié)構(gòu)庆锦，這樣的好處有：
（1）如果在開(kāi)發(fā)時(shí)有太多的分支，最后合并會(huì)很麻煩艇搀。每一次合并分支開(kāi)發(fā)人員都要花少則半個(gè)小時(shí)到一個(gè)小時(shí)焰雕，多則半天到一天的時(shí)間矩屁，合并好以后測(cè)試人員再做回歸測(cè)試吝秕。整個(gè)流程下來(lái)郭膛，一天就過(guò)去了则剃，所以我們不太贊成有太多的分支。
（2）我們持續(xù)集成的服務(wù)是監(jiān)控主干的调煎，主干上有任何代碼提交都會(huì)發(fā)現(xiàn)士袄。如果我們不去看這些分支娄柳，這些分支就不做持續(xù)集成赤拒，這樣的風(fēng)險(xiǎn)很大挎挖。
這是我們分支的策略蕉朵，我們要求每個(gè)開(kāi)發(fā)每天至少要提交一次代碼到代碼倉(cāng)庫(kù)始衅。每天提交觅闽、每天做測(cè)試就不會(huì)那么容易出現(xiàn)問(wèn)題蛉拙；如果很久才做測(cè)試的話不僅會(huì)發(fā)現(xiàn)很多問(wèn)題孕锄，而且修改起來(lái)非常費(fèi)時(shí)間畸肆。我們可以做到大概每天1.5次/人的代碼提交。
測(cè)試環(huán)節(jié)的持續(xù)集成持續(xù)測(cè)試
測(cè)試環(huán)節(jié)主要是新功能和非功能的回歸測(cè)試。每個(gè)地方都有一個(gè)圈子恬涧，圈上面有剪頭溯捆，表示持續(xù)循環(huán)地做提揍，而不是只做一次劳跃，所以我們叫“持續(xù)做測(cè)試”欺抗。我們盡量使用和生產(chǎn)環(huán)境類似的操作系統(tǒng)绞呈、數(shù)據(jù)等來(lái)做測(cè)試佃声，這樣回歸測(cè)試做完之后我們就很有信心圾亏，因?yàn)闇y(cè)試環(huán)境和生產(chǎn)環(huán)境一致志鹃，測(cè)試完之后放到生產(chǎn)環(huán)境中就很放心了曹铃。測(cè)試中我們?cè)赟hift Letf上的關(guān)注有幾點(diǎn)：
（1）需求給了開(kāi)發(fā)陕见，開(kāi)發(fā)完之后給測(cè)試评甜，大家目的不一致互相不買(mǎi)賬忍坷，討論來(lái)討論去大家開(kāi)始扯皮佩研，到底是開(kāi)發(fā)與測(cè)試對(duì)需求的理解不一樣還是什么蓖乘？再把BA等拉進(jìn)來(lái)討論，非常浪費(fèi)時(shí)間韧骗，這不是我們希望看到的嘉抒。我們希望看到的是整個(gè)自動(dòng)的流程就過(guò)去了，這樣才可以達(dá)到敏捷和快速交付的目的袍暴。所以我們會(huì)在做需求的時(shí)候就讓測(cè)試參與進(jìn)來(lái)些侍。
（2）要把測(cè)試盡早來(lái)做。我們之前在做敏捷的時(shí)候政模，開(kāi)發(fā)可以做到敏捷，然后交給測(cè)試淋样，但測(cè)試不一定能夠馬上就進(jìn)行耗式，因?yàn)檫€得部署，得找人部署到QA系統(tǒng)趁猴。原來(lái)都是手工部署刊咳，比如我們的前端有5個(gè)模塊，后端有1個(gè)模塊儡司，都部署完手工做要將近20-30分鐘娱挨。
在開(kāi)始大家工作都不是很忙的時(shí)候可以讓開(kāi)發(fā)的人幫忙部署，而在最后幾天大家都非常忙捕犬，開(kāi)發(fā)有很多需要修改的地方跷坝，沒(méi)有時(shí)間做其他的事情酵镜，所以我們必須采用自動(dòng)化部署。我們?cè)谧觥俺掷m(xù)集成”的時(shí)候有部署的腳本柴钻，做進(jìn)一步的加工和改善淮韭，讓他直接部署到這個(gè)環(huán)境。這樣QA可以直接選擇QA環(huán)境部署贴届，也可以在任何一個(gè)缺陷提交上來(lái)的時(shí)候馬上做測(cè)試靠粪。
持續(xù)回歸
測(cè)試方面我們引入的另外一個(gè)概念叫“持續(xù)回歸”。如果你最后做回歸測(cè)試的話會(huì)發(fā)現(xiàn)很多缺陷粱腻，這些缺陷再讓開(kāi)發(fā)修改庇配，時(shí)間上會(huì)有問(wèn)題。其實(shí)這也是Shift Letf的概念之一绍些，盡早做回歸測(cè)試并持續(xù)做好捞慌。我們差不多兩天左右會(huì)做一次回歸測(cè)試，持續(xù)這么做的好處在于：兩周后再做最后一輪的回歸測(cè)試就相對(duì)簡(jiǎn)單多了柬批，因?yàn)檫@個(gè)時(shí)候很多回歸上的問(wèn)題很早就被發(fā)現(xiàn)并修改了啸澡。
自動(dòng)化測(cè)試
自動(dòng)化測(cè)試非常重要，因?yàn)槌掷m(xù)化的部署和回歸測(cè)試的頻度非常高氮帐，持續(xù)化的回歸兩天一次嗅虏，如果讓QA人員做手工測(cè)試他們肯定會(huì)說(shuō)：“兩天一次怎么做得完？”這就需要進(jìn)行自動(dòng)化測(cè)試上沐。
每次自動(dòng)部署到QA環(huán)節(jié)后皮服，我們的“持續(xù)部署服務(wù)器”會(huì)調(diào)自動(dòng)化測(cè)試的框架，其次是關(guān)注在穩(wěn)定的功能模塊参咙。我不想去自動(dòng)化所有的東西龄广，這不太現(xiàn)實(shí)，我不希望我們的測(cè)試花太多時(shí)間在維護(hù)測(cè)試腳本蕴侧。
非功能的也要關(guān)注择同，以前開(kāi)發(fā)和測(cè)試更多關(guān)注功能性的需求，而非功能性的需求運(yùn)維關(guān)注得比較多净宵。很多時(shí)候會(huì)聽(tīng)到客戶關(guān)于性能的抱怨：我登陸一兩分鐘都登陸不進(jìn)去敲才。DevOps是打破壁壘，融合各個(gè)teams择葡。所以開(kāi)發(fā)和測(cè)試一定要更多地關(guān)注非功能點(diǎn)紧武，關(guān)注運(yùn)維對(duì)于性能安全方面的要求。
運(yùn)維環(huán)節(jié)的持續(xù)集成
準(zhǔn)生產(chǎn)環(huán)境
我們會(huì)給用戶做“驗(yàn)收測(cè)試”刁岸，同樣要保證他的環(huán)境和生產(chǎn)環(huán)境比較一致脏里，比如數(shù)據(jù)的一致、部署文件的一致虹曙。從持續(xù)集成開(kāi)始迫横，文件部署到ITG還是QA還是STG還是生產(chǎn)環(huán)境？部署腳本只有一個(gè)酝碳，我們只給他一個(gè)參數(shù)矾踱，說(shuō)要什么目標(biāo)，然后他去做部署疏哗。這么做的好處是什么呢呛讲？其實(shí)這個(gè)文件本身是要被測(cè)試的，否則自動(dòng)部署到生產(chǎn)環(huán)境會(huì)很危險(xiǎn)返奉。通過(guò)不斷地測(cè)試贝搁，包括QA環(huán)境每天都要部署，這么多次部署確定這個(gè)腳本沒(méi)有問(wèn)題芽偏。所有的東西都會(huì)放在代碼倉(cāng)庫(kù)里雷逆，包括腳本，部署的腳本也是從代碼倉(cāng)庫(kù)里實(shí)時(shí)拿過(guò)來(lái)再做部署污尉，這是準(zhǔn)生產(chǎn)環(huán)境膀哲。
持續(xù)部署
部署到生產(chǎn)環(huán)境，我們面臨的問(wèn)題很復(fù)雜被碗，要做很多手工的操作某宪。如何改善這最后一公里呢？我們和運(yùn)維人員商量：你們能不能不要在我每次部署的時(shí)候跟我說(shuō)“你要完成這個(gè)锐朴，要完成那個(gè)”兴喂，而是在完成之前我們就開(kāi)始合作，我部署的過(guò)程和你team一起做焚志。因?yàn)槟銓?duì)部署是有要求的衣迷，你確認(rèn)這個(gè)部署文件是OK的、符合生產(chǎn)環(huán)境中對(duì)“安全”“穩(wěn)定”各方面的要求娩嚼，包括在部署之前我們必須要做的一些安全測(cè)試蘑险、性能測(cè)試，都在我們的部署文件里被自動(dòng)觸發(fā)岳悟，一旦你認(rèn)可了佃迄，我們就用這個(gè)部署文件去部署，然后所有的日志都會(huì)被記錄下來(lái)贵少。這樣做的好處是打通了自動(dòng)化呵俏，不用再依賴于運(yùn)維人員手工部署。
在生產(chǎn)環(huán)境中我們會(huì)有監(jiān)控滔灶，整個(gè)監(jiān)控體系分為三層：業(yè)務(wù)監(jiān)控普碎、應(yīng)用監(jiān)控、系統(tǒng)監(jiān)控录平÷槌担可以看到缀皱，我們其實(shí)在開(kāi)發(fā)和部署的流程里已經(jīng)把運(yùn)維包含進(jìn)來(lái)了。包括我們現(xiàn)在用的更多的云服務(wù)动猬，用了“云”以后把運(yùn)維的一些基本服務(wù)給了云商啤斗，比如我們用亞馬遜或微軟的云，如果有問(wèn)題他會(huì)給我們發(fā)郵件提醒赁咙。
通過(guò)DevOps這樣的流程我們可以做到把原來(lái)高風(fēng)險(xiǎn)的發(fā)布變成每次發(fā)布一點(diǎn)钮莲，但發(fā)布的頻率很高。業(yè)務(wù)人員也能接受彼水，有的時(shí)候他們要做一些緊急的業(yè)務(wù)更改崔拥，在之前得到的答復(fù)是：等三個(gè)月，三個(gè)月之后給你凤覆，這樣他肯定不愿意链瓦，因?yàn)榫o急上線；現(xiàn)在得到的答復(fù)是：沒(méi)關(guān)系叛赚，兩個(gè)禮拜以后就可以給你澡绩，業(yè)務(wù)人員更愿意接受后者，因?yàn)榭梢员ＷC生產(chǎn)的穩(wěn)定俺附，保證開(kāi)發(fā)的順暢肥卡。這就是DevOps能夠幫助我們解決的問(wèn)題，減少發(fā)布的風(fēng)險(xiǎn)事镣，全流程自動(dòng)化順暢步鉴。
三、DevOps帶來(lái)的好處
1璃哟、由代碼的提交觸發(fā)：消除等待時(shí)間+快速反饋給業(yè)務(wù)和開(kāi)發(fā)人員氛琢。 2、每個(gè)變化對(duì)應(yīng)一個(gè)交付管道：使問(wèn)題定位和調(diào)試變得簡(jiǎn)單随闪。 3阳似、全流程自動(dòng)化：穩(wěn)定，快速铐伴，交付結(jié)果可預(yù)測(cè)撮奏。 4、持續(xù)進(jìn)行自動(dòng)化回歸測(cè)試：提升交付質(zhì)量当宴。 5畜吊、設(shè)施共享并按需提供：資源利用最大化。
這是DevOps在敏捷方面的實(shí)施户矢。敏捷大家很熟悉玲献，比如四周一個(gè)敏捷項(xiàng)目：第一周做敏捷的迭代、計(jì)劃會(huì)議，周一開(kāi)始做了捌年，開(kāi)完會(huì)之后開(kāi)發(fā)和測(cè)試以及po或ba一起再討論一下瓢娜，周四開(kāi)發(fā)，開(kāi)發(fā)到第三周結(jié)束延窜，接下來(lái)是回歸恋腕、驗(yàn)收測(cè)試抹锄、發(fā)布上線這樣的流程逆瑞。敏捷通常最后我們會(huì)部署在stg給PO做Demo，為了盡可能早的發(fā)現(xiàn)問(wèn)題伙单，我們會(huì)在第二周的周四或第三周的周三部署已完成的部分到STG获高，有的時(shí)候業(yè)務(wù)人員提需求的時(shí)候想得也不是很明白，等你做完之后他可能又會(huì)覺(jué)得不是很好吻育，所以就要盡早測(cè)試念秧，有問(wèn)題盡早改，最后我們發(fā)布到生產(chǎn)環(huán)境做冒煙測(cè)試布疼，然后這里再創(chuàng)建一個(gè)新的分支摊趾。所有的測(cè)試都是循環(huán)使用，所有的代碼都放在代碼倉(cāng)庫(kù)里游两。
四砾层、持續(xù)部署Pipeline和工具、DevOps業(yè)界工具鏈
五贱案、這就是DevOps
開(kāi)發(fā)測(cè)試運(yùn)維之前各自為政肛炮，現(xiàn)在融為一體能夠協(xié)同的合作，幸福的生活在一起宝踪，這個(gè)就是DevOps的文化所關(guān)注的侨糟。
