DevOps是一種強調(diào)軟件開發(fā)人員與IT運營商之間的通信，協(xié)作，集成，自動化和合作的開發(fā)方法，在2015年一直是IT界永恒的主題。DevOps可能不是一個新概念，但它正在開始輸入黃金時間使用情況。如果Gartner的預測是正確的，那么到2016年，全球前2,000家組織中約有四分之一將使用DevOps。

DevOps用途的擴大和實現(xiàn)的潛在好處推動了多種技術(shù)的創(chuàng)新，包括Jenkins，Chef，Puppet和軟件定義基礎(chǔ)架構(gòu)的迅速普及。幾乎巧合的是，但也許不是完全獨立的，包括微服務和容器（例如Docker）在內(nèi)的新應用程序部署模型變得越來越流行。所有這些元素都有助于連接開發(fā)人員和運營團隊。

DevOps無疑對企業(yè)簡化產(chǎn)品開發(fā)流程的方式產(chǎn)生了重大影響。當在更廣泛的持續(xù)交付（CD）方法的背景下考慮DevOps時，可以獲得最大利益的地方。根據(jù)2014年Evans Data Research的數(shù)據(jù)，即使在那時，CD仍在某種程度上被所有接受調(diào)查的組織的三分之二采用，即使它們沒有使用CD標簽。有跡象表明，即使那些尚未開始采用CD的組織也打算至少在不久的將來這樣做。

DevOps和CD是很好的搭配。持續(xù)交付就是要創(chuàng)建一個更具協(xié)作性，凝聚力和及時性的環(huán)境，以將軟件項目從啟動到部署，并隨時準備將其發(fā)布到生產(chǎn)環(huán)境中。持續(xù)交付的關(guān)鍵是使用從自動構(gòu)建和測試系統(tǒng)以及客戶到計劃管道的快速反饋循環(huán)。成功的CD可以使用多種技術(shù)：確保產(chǎn)品始終（至少在理論上）可發(fā)布；釋放周期保持較短，可以重新確定優(yōu)先級；根據(jù)反饋調(diào)整計劃；并以可管理的小塊形式發(fā)布。畢竟，傳統(tǒng)的“瀑布式”項目的主要問題之一是那些僅每12或24個月發(fā)布一次的實例。這些較長的發(fā)布周期通常意味著它們包含許多更改，因此無法確定哪些實際有效或存在錯誤。成功的機會很小。

CD的一個極端示例可能是主要的Web服務，例如Amazon或Facebook，它們可能每小時（甚至每分鐘）多次發(fā)布更新到生產(chǎn)中。這可能不是大多數(shù)公司想要（或可以管理）的模式，但即使是每周或每月發(fā)布也對許多公司構(gòu)成挑戰(zhàn)。如果發(fā)布周期要盡可能短，那么很清楚為什么以正確的方式執(zhí)行DevOps是CD成功的主要推動力。DevOps的目標是消除傳統(tǒng)上已經(jīng)中斷了從開發(fā)人員到客戶的變更流程的“減速帶”，并且事實證明，這種“減速帶”常常是阻礙CD普及的最大障礙。

成功的DevOps和持續(xù)交付

到目前為止，至少在理論上如此好：將其轉(zhuǎn)換為實際成功的部署是另一回事。建立適當?shù)墓ぞ哝準且粋€好的開始。還需要開發(fā)一個易于理解的過程。但是，最有影響力的因素可能是采用正確的文化。解決發(fā)展與運營之間的文化沖突問題沒有簡單的“一刀切”的解決辦法，但從根本上說，成功的關(guān)鍵是信任，而與此密切相關(guān)的是可見性。開發(fā)人員應了解運營團隊的需求；運營團隊應該了解開發(fā)人員正在構(gòu)建什么，并與他們一起創(chuàng)建易于部署和管理的應用程序。

這并不是說選擇正確的工具并不重要?，F(xiàn)有的工具可能會阻礙（甚至禁止）DevOps和CD的成功采用，因此這可能是重新評估當前工具集和流程的時候了。不管使用哪種工具，在過去的幾年中，都有一些非常清晰的“最佳實踐”步驟。根據(jù)與客戶合作的經(jīng)驗，以下是我要考慮的五個方面：

1.超越代碼思考

所有資產(chǎn)都需要作為項目的一部分進行控制-藝術(shù)品，設(shè)計，文檔，配置腳本，二進制文件等-否則存在釋放不完整或不一致的應用程序的實際風險，最終導致客戶不滿意。

2.自動化

自動化流程有助于減少出錯的機會，并減少對單個英雄的依賴。雖然并非項目的每個方面都可以自動化，但更多的方面可以增強可預測性和可重復性，從而支持更快，更高效的發(fā)布流程。成功的DevOps和CD取決于統(tǒng)一，連續(xù)的管道，該管道在流程的每個步驟都支持自動化。

3.智能測試

將自動化測試計劃為持續(xù)集成（CI）流程的一部分。需要仔細計劃以確保足夠的覆蓋范圍，而又不要太慢以至于無法快速發(fā)布。選擇正確的工具和硬件是重要的因素，但是進行“正確的”測試也是如此，且測試數(shù)量不超過所需數(shù)量。沒有簡單的方法可以預測這意味著什么以及需要在每個項目的上下文中加以考慮。測試的反饋必須迅速返回給開發(fā)人員進行處理。切記還要首先考慮如何將安全測試合并到測試計劃中以及如何將安全要求包括在項目計劃中。

4.版本一切

良好的CD和DevOps結(jié)合的核心是所有資產(chǎn)或工件的單一，高度透明的存儲庫。這不僅意味著具有了解當前正在發(fā)生的事情（以及誰在做什么）的能力，而且還具有從創(chuàng)建到部署的“歷史”，具有明確的責任感，并且可以選擇“回滾”到以前的版本需要。

高質(zhì)量的跟蹤意味著所有更改和相互依賴性都作為完整的版本提供，從而使執(zhí)行任何調(diào)試更加容易。為此選擇版本控制引擎時，請考慮它是否可以處理所需的所有不同工件類型，以及是否可以隨著組織產(chǎn)品或分布式開發(fā)環(huán)境的增長而擴展。版本管理工具是否足夠快以支持快速且頻繁的CI構(gòu)建和測試？

考慮安全性也很重要：畢竟，所有源代碼，設(shè)計等都可能代表您組織的最有價值的知識產(chǎn)權(quán)。許多現(xiàn)有的版本控制系統(tǒng)可能不具備這些功能，因此就DevOps和CD而言，不適合特定用途。

5.工具和文化需要協(xié)同工作

版本控制之類的工具起著重要的輔助作用，但是文化態(tài)度決定一切。除了獲得管理層的支持外，成功采用CD和DevOps的人還發(fā)展了內(nèi)部“冠軍”，他們可以教育和幫助同齡人。

DevOps和Continuous Delivery都具有巨大的潛力，可以改善甚至改變各種組織內(nèi)部的生產(chǎn)和發(fā)布周期。從一開始就確保工具，流程和文化的正確基礎(chǔ)將有助于將這一承諾變成可證明的改進。