大多數(shù)組織都希望能夠快速地從負(fù)責(zé)IT平臺的團(tuán)隊(duì)獲得反饋。盡管IT對于企業(yè)的運(yùn)作至關(guān)重要,但它要遠(yuǎn)比推動者具有更強(qiáng)大的業(yè)務(wù)約束力。
事實(shí)證明,關(guān)鍵業(yè)務(wù)應(yīng)用程序開發(fā)的瀑布式方法無法解決該問題。而DevOps是一種旨在得到快速反饋的方法,開發(fā)者快速地將代碼提供給運(yùn)營基礎(chǔ)設(shè)施,這樣就可以使IT在問題發(fā)生時及時作出響應(yīng)。
具有循序漸進(jìn)、持續(xù)集成和交付的DevOps思維模式對于消費(fèi)者來說非常熟悉,但是在企業(yè)環(huán)境中進(jìn)行應(yīng)用測試和培訓(xùn)時卻面臨著挑戰(zhàn)。在完整的DevOps工具列表工具支撐下,企業(yè)不得不轉(zhuǎn)向持續(xù)交付的思維方式:定期、快速有效地交付細(xì)小變動更易于桌面用戶和終端用戶接受。
在DevOps部署中,開發(fā)者必須非常精通業(yè)務(wù),即圍繞業(yè)務(wù)影響力構(gòu)建項(xiàng)目,而不是構(gòu)建技術(shù)上更有吸引力的項(xiàng)目。即使現(xiàn)在IT平臺具有復(fù)雜的相互依存關(guān)系,操作技術(shù)人員也不應(yīng)該害怕產(chǎn)品的改變。通過合理地管理和工具從正確的地方獲取精準(zhǔn)信息,細(xì)小的改變相比一個完整的大規(guī)模升級更加容易處理,而且大規(guī)模的版本升級回滾是一個很漫長的問題。
想要獲得更好的IT環(huán)境,DevOps并無捷徑。它需要重復(fù)考慮如何管理IT交付,以及一致、強(qiáng)大的流程處理工具。
DevOps工具列表
和混亂的路線相比,DevOps的成功和什么有關(guān)呢?當(dāng)然并不是指其給予了(開發(fā)和運(yùn)營)兩個團(tuán)隊(duì)對IT完全的控制自由。企業(yè)需要一整套的流程來完成捕捉業(yè)務(wù)需求和區(qū)分業(yè)務(wù)需求優(yōu)先級;對新的或變更的技術(shù)進(jìn)行需求規(guī)劃;有效測試其性能;提供階段性代碼,并以最可能低的代價(jià)和風(fēng)險(xiǎn)實(shí)現(xiàn)它。
大型的、長期的項(xiàng)目不得不消逝。IT組織者必須將業(yè)務(wù)需求分成必要的流程,再將流程分成若干任務(wù),然后審視這些任務(wù),并且識別在IT環(huán)境中是否已經(jīng)有滿足那些要求的服務(wù)。不需要再讓開發(fā)人員創(chuàng)建另一個類似的功能——重復(fù)使用這些功能以確保支持和負(fù)載的可移植性正常。也要關(guān)注外部服務(wù),這些服務(wù)可以被應(yīng)用程序接口 (API)調(diào)用。為了監(jiān)控和管理這些API,就需要評估API管理工具,例如Apigee和TIBCO Mashery。
然后,為DevOps選擇開發(fā)工具。許多開發(fā)者已經(jīng)建立了定制工具包,而不是使用保守的來自微軟、IBM和其他供應(yīng)商的工具包。為了實(shí)現(xiàn)開發(fā)-運(yùn)營過程中的個性化控制,他們可能會選擇開放系統(tǒng),例如Ruby on Rails或者Python系統(tǒng),以及帶有版本控制和配置管理的系統(tǒng),例如Jenkins、Chef和Puppet系統(tǒng)。
由于團(tuán)隊(duì)開發(fā)的特性,合作管理是關(guān)鍵。這可以體現(xiàn)在一個簡單的層面,例如使用線上工具,例如Redbooth(先前的Teambox)或者Basecamp,或者現(xiàn)場工具CAPPM,或者復(fù)合工具Clarizen。后面介紹的工具可以允許團(tuán)隊(duì)將代碼儲存在一個單一的地方,這個地方具有文件和外圍信息,并且有能力管理項(xiàng)目任務(wù)的進(jìn)程。也有全面的源代碼管理(SCM)工具,例如那些來自Serena Software和IBM Rational的軟件,同時還有開源工具,例如由elego Software Solutions或者Git開發(fā)的DCVS工具。
不要急于通過用戶可接受性測試獲得代碼,也不要急于進(jìn)入分階段式操作環(huán)境。檢查和權(quán)衡是非常必要的,這伴隨著自動化監(jiān)控,以確保監(jiān)控每個流程,采取立即措施時提出問題。對于提供具有自動化和監(jiān)測的DevOps流程的系統(tǒng),可以考慮由HashiCorp供應(yīng)商提供的Altas產(chǎn)品——這是其獨(dú)家的工具集合,例如Vagrant, Packer等等——Eletric Cloud與其ElectricFlow,或者IBM產(chǎn)品,可以提供Bluemix作為開發(fā)、包裝和配置的平臺。Atlassian是另一家提供自動化測試和配置工具的公司。
DevOps應(yīng)用程序盡可能地使用虛擬容器。容器能夠允許對代碼更好的控制和管理,推動開發(fā)者向一個更加靈活的微服務(wù)模型前進(jìn)。該領(lǐng)域的領(lǐng)軍目前是Docker,但CoreOS Rocket項(xiàng)目也展示出很有潛力,Apache Tomcat 也是個很有力的競爭者,但似乎還不能和Docker齊平。
鏈接你的DevOps工具鏈
此時此刻,DevOps仍然還是一個新興的方法,缺乏總體成熟的市場。而且,對于任何公司來說,不可能通過單一的工具帶來完美的DevOps策略。因此要充實(shí)你的DevOps工具列表,對每項(xiàng)給定任務(wù)提供最佳的平臺,并且要著眼于未來。避免使用那些由老舊的SCM系統(tǒng)更名而來,并且將DevOps作為營銷策略的工具;并且隨著新技術(shù)的到來,確保你的開發(fā)者和IT操作人員所使用的工具能夠靈活適應(yīng)新技術(shù)。
停止尋找綜合性的DevOps工具——因?yàn)椴]有銀彈。相反,也要確保你所選擇的子彈不會射到你自己的腳。