2015年，開(kāi)發(fā)部和運(yùn)營(yíng)部仍然會(huì)有千絲萬(wàn)縷的聯(lián)系，因?yàn)檫@兩個(gè)部門會(huì)共用許多有利于二者關(guān)系順暢的工具及平臺(tái)。但是，所面臨的挑戰(zhàn)是，我們僅僅得到未來(lái)五年意義深遠(yuǎn)的變革承諾而已。跟其他許多流行趨勢(shì)一樣，當(dāng)DevOps成為商用環(huán)境中一個(gè)籠統(tǒng)的稱謂時(shí)，那么它受人關(guān)注的程度就會(huì)淡化。Jevgeni Kabanov對(duì)此表示無(wú)奈與遺憾。“我對(duì)DevOps這個(gè)主題有些不解，因?yàn)椋也淮_定其定義是否完善。它起到一個(gè)旗幟的作用，我真的想要讓操作系統(tǒng)朝著它的方向發(fā)展。”然而，Kabanov卻指出，許多工具集和解決方案都被標(biāo)上DevOps標(biāo)簽，但是我們卻不理解實(shí)際運(yùn)行中究竟是什么樣。
DevOps仍不具備精確性
ZeroTurnaround公司的創(chuàng)始人兼首席執(zhí)行官是如何定義這個(gè)概念呢?Kabanov跟我們是這樣解釋的：“我認(rèn)為DevOps包含兩部分。一部分是要打破開(kāi)發(fā)與運(yùn)營(yíng)之間的壁壘。這個(gè)兩個(gè)部門都會(huì)擔(dān)憂他們?cè)撊绾螢橄M(fèi)者創(chuàng)造價(jià)值，無(wú)論他們是內(nèi)部消費(fèi)者還是外部消費(fèi)者。另外一部分則更像是來(lái)自于開(kāi)發(fā)人員所帶來(lái)的一種潮流，因?yàn)樗麄冊(cè)谶\(yùn)行過(guò)程中使用更多的開(kāi)發(fā)技術(shù)。如今所編輯的運(yùn)行程序中越來(lái)越多的添加了Chef、腳本基礎(chǔ)架構(gòu)、云以及部署等功能。這些功能都有助于讓持續(xù)交付的程序可以正常運(yùn)行并返回到構(gòu)建的路徑上。這種模式適用于整個(gè)生命周期中。”
實(shí)現(xiàn)持續(xù)交付
Karsten Bugner是Pernexus Systems的技術(shù)總監(jiān)，他對(duì)公司最近開(kāi)始使用的XRebel和JRebel開(kāi)發(fā)工具給予了高度的肯定。當(dāng)證實(shí)傳統(tǒng)的開(kāi)發(fā)方式會(huì)降低開(kāi)發(fā)效率時(shí)，公司決定進(jìn)行轉(zhuǎn)變。“從某一刻開(kāi)始，自動(dòng)分類和注釋就不再起任何作用了，在任何一個(gè)階段和類別中都過(guò)于沉重而不能順利地在攔截器中運(yùn)行。此時(shí)，我們就應(yīng)該尋找解決方案來(lái)重新分類、裝配。”
在無(wú)需總是重新啟動(dòng)服務(wù)器的情況下，Bugner迅速地學(xué)會(huì)了如何運(yùn)用這種功能并反復(fù)進(jìn)行部署。與標(biāo)準(zhǔn)分析工具相比，他對(duì)現(xiàn)在這種帶有輕量級(jí)工具更滿意一些。“使用像JProbe這樣的標(biāo)準(zhǔn)工具，你可以找到所有文件。我們已經(jīng)擁有了一種知名的分析工具，想要找到所需信息需要花費(fèi)一到兩個(gè)小時(shí)的時(shí)間。有了 Xrebel，你不會(huì)再為時(shí)間問(wèn)題而苦惱，而是會(huì)更加迅速得地完成指定任務(wù)。”
首先要注重理念，其次才是工具
Simon Maple在ZeroTurnaround公司的推廣部工作，他對(duì)SonarSource贊不絕口，因?yàn)樗梢源_保代碼質(zhì)量。但是，他所說(shuō)的質(zhì)量是從兩個(gè)方面進(jìn)行判斷的，其一是要選擇合適的工具，其二就是將其運(yùn)用到實(shí)際工作中。不幸的是，許多開(kāi)發(fā)團(tuán)隊(duì)在執(zhí)行方面通常達(dá)不到預(yù)期的效果。
“通常，第一次開(kāi)發(fā)人員使用一種質(zhì)量工具，然后他們便會(huì)將其放下，形成一種擺設(shè)而已。持續(xù)使用合適的代碼質(zhì)量工具才能保證軟件的開(kāi)發(fā)質(zhì)量。我們應(yīng)該將這些工具反復(fù)整合到開(kāi)發(fā)流程中。它們應(yīng)該成為構(gòu)建流程的一部分，從而當(dāng)這些工具發(fā)現(xiàn)問(wèn)題時(shí)，構(gòu)建才會(huì)徹底失敗。”
從實(shí)用性角度來(lái)看，我們可以從兩個(gè)方面解讀DevOps。一是Ops，它可以使開(kāi)發(fā)過(guò)程更加順暢。二是Dev，重新對(duì)如何實(shí)現(xiàn)運(yùn)行系統(tǒng)的無(wú)縫部署和管理進(jìn)行思考。這就意味著，Dev和Ops不能分開(kāi)進(jìn)行。
Maple認(rèn)為，二者的分離仍會(huì)產(chǎn)生很大的問(wèn)題。“開(kāi)發(fā)人員能否在同一生產(chǎn)環(huán)境中進(jìn)行有效測(cè)試是非常重要的一個(gè)環(huán)節(jié)。我仍然看到有些客戶正使用著Jetty開(kāi)發(fā)環(huán)境，然后變化轉(zhuǎn)向WebSphere生產(chǎn)環(huán)境。使用這種方法，一些嚴(yán)重的質(zhì)量問(wèn)題便會(huì)影響到程序編碼。使用一些簡(jiǎn)單的方法就會(huì)解決這些問(wèn)題。這種簡(jiǎn)單的方法就是改變?nèi)藛T開(kāi)發(fā)高質(zhì)量軟件的心態(tài)，而不是僅僅改變開(kāi)發(fā)工具。”
為了實(shí)現(xiàn)更好的DevOps做出最佳選擇
定義DevOps：對(duì)于該方法來(lái)說(shuō)，或許不僅僅只有一種定義。但是，至少在任何一個(gè)組織中， DevOps所要實(shí)現(xiàn)的目標(biāo)和成果應(yīng)該是可以達(dá)到統(tǒng)一的。達(dá)成共識(shí)，然后，從那里開(kāi)始工作。
重新構(gòu)思工具：如果現(xiàn)有工具阻礙了持續(xù)交付的進(jìn)度，那么就應(yīng)該做出一個(gè)新的選擇，在不降低質(zhì)量的情況下實(shí)現(xiàn)更高的生產(chǎn)力。我們應(yīng)該決定多大的信息量才足以交付工作軟件。
關(guān)注流程和實(shí)踐：工具改變不了人們的文化。仔細(xì)觀察目前的DevOps流程，找到需要改進(jìn)之處。為了形成更好的實(shí)踐，我們應(yīng)該采用一些培訓(xùn)和激勵(lì)政策，同時(shí)協(xié)作地使用一些恰當(dāng)?shù)墓ぷ鱽?lái)支持這些改變。
京公網(wǎng)安備 11010502049343號(hào)