當一個名詞被不斷提及，就是火了嗎?但是，受關注的程度與被了解并很好的執行并不一定成正比。DevOps，就是一個例子。對于DevOps的定義，有人說是一組流程、有人說是一個概念、有人說是應用開發和系統運維團隊執行任務的混合體、有人說是一個新興的軟件集成以及IT業務的溝通協作方式、還有說是一個軟件方法……這些理解，你認為都對嗎?

[[138110]] 

　　DevOps的演進

　　先來看看DevOps是怎么發展起來的?一開始DevOps由兩個運動組成，第一個，被稱之為敏捷系統管理的運動，觸發點是2008年舉辦的Velocity Conference會議，主要討論關于Web的運維，以提高整個web運維的效率。之后，2009年的時候由Gordon Banner正式地推展敏捷系統管理的運動。第二個，對DevOps的歷史有影響的運動叫企業系統管理的運動，在2000年中旬的時候，由John Willis和Mark Hinkle這兩個人開始。這兩個運動的結合也就是DevOps的運動。

　　開發人員VS運維人員

　　平時，在工作當中，我們常常遇到相關不同角色的一些同事，甚至同處于一個項目中，像開發人員，環境準備人員，測試人員，運維人員，以及負責應用支援的人員、業務主管等。但經常各自劃分了"領地"，開發的同事常會告訴我們說，我用了70%時間來等待;環境準備人員常常談論沒有多余的環境了;測試人員常常告訴我們說，測試環境不夠真實，運維的同事會說應用發布就是噩夢，應用支援的同事更慘，常會問怎么找問題?但是，你發現沒，里面缺少了一個很重要的角色，就是業務主管，“業務主管常常會對IT部門說：“你們IT在做什么，我們正在錯過外面所帶來的業務的機會，我需要新的應用，我需要新的功能……”。可見，各角色僅關注于自己本身的工作，而非各角色之間的分界點。

　　IT正處在變革當中，現在大家在談論最多的就是應用經濟，因為，應用經濟所帶來的機會是巨大的。但是，很多時候我們發現沒有很好的抓住這些機會，其實這是由于IT創新能力的低下。面對業務所帶來的需求，我們仍選擇的是二十年前開發應用的方式來進行應用運維，這說明，IT需要補足這個差距。

　　到底是什么導致停滯不前呢?根據Forrester的調查數據顯示，低于40%的決策者認為IT能按時，按預約提供新服務，75%的決策者認為有必要提高整體IT的效率，這里面包含 IT的效率、創新的能力、簡化的流程、工作的效率。

　　DevOps的精髓，整體觀念

　　那么，問題怎么解決呢?IT部門的骨干是有兩個最主要的工作部門組成的，一個是研發(Development)另外一個是運維部門(Operations),他們都有自己的思維方式來做事，研發同事常會需要快速地創新，寫簡易的代碼，簡單使用，Agile交付等更多功能上。而負責運維的同事有另外一套思維模式，需要系統穩定地運行，最好是十年都不做任何的改變，完善的安全機制，更簡易的管理步驟等等。

　　而如何把這雙方的差異點整合起來，就是DevOps的精髓。DevOps(開發運維)是Development與operation這兩個詞所組成的。CA公司認為，DevOps所要達到的目的是確保穩定的創新，使用敏捷開發來交付應用，敏捷運維來運維應用，這是DevOps整體的觀念。

　　整合開發和運維人員

　　目前，在高速競爭的市場，如何快速地把應用推出，如何快速地交付新的服務，成為IT不可避免的問題。那么，一套增強開發及運維之間的集成，協作及溝通的方法是很有必要的。而DevOps恰巧就能協助各個企業解決這個問題，快速地把應用交付出來。

　　DevOps首先，可以更快地交付業務的價值，在服務交付的過程中打破孤島，即打破開發與運維之間溝通的成本;第二，整合開發和運維的能力成為一個協作的團隊，他們不再是開發，不再是運維，而是IT的團隊。第三，DevOps最主要專注的是端到端服務交付流程的變革。

　　當實現整個DevOps的交付過程當中，必須要確保流程的變革、新式工具的推廣、或者新工作流程推廣的時候是不影響安全性，應用的兼容性，以及應用的性能，這是DevOps所需要帶來的一個價值。

　　DevOps的終極目標，持續交付

　　那么 DevOps的終極目標是什么?CA稱之為持續交付。DevOps打破信息的孤島，讓開發與運維之間更好的協作。協作目的是確保應用能快速地由開發流轉到測試，再到運維。當運維遇到問題的時候，能建制一個完整的閉環回到開發環節。

　　我們知道，一個應用的開始都是由開發人員開始把我們的應用開發完成了，當然我們前端還有我們的相關業務部門，業務部門把這個需求提給開發，開發的同事分析完需求之后進行他們的開發，開發完之后相關的代碼我們會放到我們的代碼庫上，這是大家現在常做的做法。

　　在一個持續交付的觀念里面，開始由相關業務部門根據需求提供給開發人員，開發人員分析完需求并并行開發，開發完成后，相關的代碼會放到代碼庫中。這時候應該有一個持續集成，也就是構建自動化(Continuous integration)平臺，平臺提供開源的工具、持續集成的工具、build的工具來進行建制持續的集成。

　　CA DevOps解決方案

　　持續集成的結果就是工件，工件可以存到代碼庫上，之后讓持續集成工具開始來呼叫CA的應用發布解決方案，——CA DevOps解決方案，將會由工件庫把最新的工件取下來，比如， ear file, war file, jar, exe 等等，這時，會自動結合發布清單把相關的應用透過已經定制好的發布流程，發布到SIT環境上去。

　　那么問題來了，在正常的狀況下，手工進行SIT的測試，為了實現持續交付的目的，自動化的測試變成必不可缺的一個環節。在這個環節上CA DevOps解決方案能呼叫下一個解決方案(CA Service Virtualization)。CA服務虛擬化包含了兩個部分，第一部分是測試的發起端，它包含錄制網頁的一些測試腳本，也包含透過傳輸協議直接發起的測試，甚至包含移動終端的一些應用的測試。

　　另外一部分，是能把測試過程當中應用所依賴的第三方的內外部的資源，透過服務虛擬化解決方案資源透過一定的手段虛擬出來，這樣就能達到真正的自動化測試。當啟動服務虛擬化之后，能自動針對SIT環境上面所部署的應用進行自動化完整的測試。

　　在測試過程當中一切順利的話，下一步會回饋到自動化的解決方案平臺，將會針對下一個環境UAT的參數、配置，跟當初所測試的工件做一個集合，然后發布到UAT環境上去，同樣，使用CA服務虛擬化解決方案，直接進行自動化完整測試。若測試過程當中發現某一個錯誤發生了，就能自動地回滾。 CA DevOps解決方案平臺能自動把應用回滾成舊的版本，而且是在各個環境當中都能自動地都回滾成舊版本。

　　接下來CA DevOps解決方案平臺用同樣的工件結合同樣環境發布清單，把應用完整地發布到生產環境上面去。而在生產環境上會面臨一個挑戰，就是沒有辦法進行任何流程或是交易測試。原因很簡單，因為在生產環境上做任何測試都會影響到生產的數據。所以，往往發布之后是沒辦法進行完整的測試，只能等到使用者上線使用的時候才可能發現問題。但是在高競爭的環境底下，當發現問題已經太遲了。透過CA服務虛擬化解決方案，在測試環境上就開始進行相對驗證了，在這個場景下除了應用是真實的，發起端、接收端都是虛擬的。這樣進行完整應用的交易測試以及確認應用發布完成，一切正常。

　　CA DevOps解決方案平臺還有一個特性，就是在發布過程當中把所有的數據記錄下來，比如，做過的動作，進行的工作，都完整地記錄下來，供后續的發布報告分析。

　　DevOps的終極目標，也就是持續的交付。出發點是為確保提高整體IT的運維，研發，以及交付能力效率。CA DevOps解決方案平臺做到了這一點。