2015年，開發(fā)部和運營部仍然會有千絲萬縷的聯系，因為這兩個部門會共用許多有利于二者關系順暢的工具及平臺。但是，所面臨的挑戰(zhàn)是，我們僅僅得到未來五年意義深遠的變革承諾而已。跟其他許多流行趨勢一樣，當DevOps成為商用環(huán)境中一個籠統(tǒng)的稱謂時，那么它受人關注的程度就會淡化。Jevgeni Kabanov對此表示無奈與遺憾。“我對DevOps這個主題有些不解，因為，我不確定其定義是否完善。它起到一個旗幟的作用，我真的想要讓操作系統(tǒng)朝著它的方向發(fā)展。”然而，Kabanov卻指出，許多工具集和解決方案都被標上DevOps標簽，但是我們卻不理解實際運行中究竟是什么樣。

DevOps仍不具備精確性

ZeroTurnaround公司的創(chuàng)始人兼首席執(zhí)行官是如何定義這個概念呢?Kabanov跟我們是這樣解釋的：“我認為DevOps包含兩部分。一部分是要打破開發(fā)與運營之間的壁壘。這個兩個部門都會擔憂他們該如何為消費者創(chuàng)造價值，無論他們是內部消費者還是外部消費者。另外一部分則更像是來自于開發(fā)人員所帶來的一種潮流，因為他們在運行過程中使用更多的開發(fā)技術。如今所編輯的運行程序中越來越多的添加了Chef、腳本基礎架構、云以及部署等功能。這些功能都有助于讓持續(xù)交付的程序可以正常運行并返回到構建的路徑上。這種模式適用于整個生命周期中。”

實現持續(xù)交付

Karsten Bugner是Pernexus Systems的技術總監(jiān)，他對公司最近開始使用的XRebel和JRebel開發(fā)工具給予了高度的肯定。當證實傳統(tǒng)的開發(fā)方式會降低開發(fā)效率時，公司決定進行轉變。“從某一刻開始，自動分類和注釋就不再起任何作用了，在任何一個階段和類別中都過于沉重而不能順利地在攔截器中運行。此時，我們就應該尋找解決方案來重新分類、裝配。”

在無需總是重新啟動服務器的情況下，Bugner迅速地學會了如何運用這種功能并反復進行部署。與標準分析工具相比，他對現在這種帶有輕量級工具更滿意一些。“使用像JProbe這樣的標準工具，你可以找到所有文件。我們已經擁有了一種知名的分析工具，想要找到所需信息需要花費一到兩個小時的時間。有了 Xrebel，你不會再為時間問題而苦惱，而是會更加迅速得地完成指定任務。”

首先要注重理念，其次才是工具

Simon Maple在ZeroTurnaround公司的推廣部工作，他對SonarSource贊不絕口，因為它可以確保代碼質量。但是，他所說的質量是從兩個方面進行判斷的，其一是要選擇合適的工具，其二就是將其運用到實際工作中。不幸的是，許多開發(fā)團隊在執(zhí)行方面通常達不到預期的效果。

“通常，第一次開發(fā)人員使用一種質量工具，然后他們便會將其放下，形成一種擺設而已。持續(xù)使用合適的代碼質量工具才能保證軟件的開發(fā)質量。我們應該將這些工具反復整合到開發(fā)流程中。它們應該成為構建流程的一部分，從而當這些工具發(fā)現問題時，構建才會徹底失敗。”

從實用性角度來看，我們可以從兩個方面解讀DevOps。一是Ops，它可以使開發(fā)過程更加順暢。二是Dev，重新對如何實現運行系統(tǒng)的無縫部署和管理進行思考。這就意味著，Dev和Ops不能分開進行。

Maple認為，二者的分離仍會產生很大的問題。“開發(fā)人員能否在同一生產環(huán)境中進行有效測試是非常重要的一個環(huán)節(jié)。我仍然看到有些客戶正使用著Jetty開發(fā)環(huán)境，然后變化轉向WebSphere生產環(huán)境。使用這種方法，一些嚴重的質量問題便會影響到程序編碼。使用一些簡單的方法就會解決這些問題。這種簡單的方法就是改變人員開發(fā)高質量軟件的心態(tài)，而不是僅僅改變開發(fā)工具。”

為了實現更好的DevOps做出最佳選擇

定義DevOps：對于該方法來說，或許不僅僅只有一種定義。但是，至少在任何一個組織中， DevOps所要實現的目標和成果應該是可以達到統(tǒng)一的。達成共識，然后，從那里開始工作。

重新構思工具：如果現有工具阻礙了持續(xù)交付的進度，那么就應該做出一個新的選擇，在不降低質量的情況下實現更高的生產力。我們應該決定多大的信息量才足以交付工作軟件。

關注流程和實踐：工具改變不了人們的文化。仔細觀察目前的DevOps流程，找到需要改進之處。為了形成更好的實踐，我們應該采用一些培訓和激勵政策，同時協(xié)作地使用一些恰當的工作來支持這些改變。