原文地址:http://www.drdobbs.com/architecture-and-design/what-exactly-is-devops/240009147 做者:Neil Garnichaud網絡
軟件開發目前的最新趨勢是DevOps文化，即開發人員和運營人員一塊兒確保軟件以最低的故障率運行。工具
不少組織發現他們面臨這樣的挑戰，即隨着雲的Web應用程序的發展，要求快速發佈以便及時響應來自用戶社區的問題或請求。及時響應用戶需求是每一個軟件開發團隊的目標，可是會給組織內的功能團隊形成壓力。壓力每每致使更多的缺陷和對團隊持續性的打斷。DevOps經過構建一種開發和運營（這就是DevOps名字的由來）之間的關係來試圖解決該問題。在該結構中，開發團隊支持運營需求，好比部署腳本，異常診斷，以及從週期最開始就進行的負載和性能測試；而運營團隊在軟件部署前，部署時及部署後向開發團隊提供知識支持和及時的反饋。性能
DevOps是不少軟件開發團隊正在前進的方向。他們以前忍受着組織給予的壓力，即在QA缺乏時間測試的狀況下還要生產高質量的代碼。而DevOps是一個新的環境，若是開發人員想要成功，就不得不有所調整。在截止期限的壓縮，分爲開發，QA，產品的故事牆成爲了敏捷的阻礙。DevOps試圖打破這個牆。如今，團隊協做能力變得與技術能力同樣重要。所以，單一關注最終用戶的體驗，來看其是如何影響業務的。DevOps並非新的工具或組織，而是新的文化和流程。它是開發，QA以及運營相互工做來加快開發和解決問題。測試
爲何開發人員須要DevOps
DevOps對於開發人員來講是好事。開發人員想工做於DevOps爲導向的組織中，有三個主要的緣由：日誌
更好的生活質量。DevOps模式的開發人員不多會在半夜接到電話要求解決產品問題。這是由於問題在產生災難性以前已經被發現，主動監控比被動警告要好的多。開發
引覺得豪的全部權。傳統的軟件流程中，一旦軟件被部署，就被「甩手扔給了」QA，而後甩手扔到了產品環境。因此最終用戶看到的可能與開發人員編寫的徹底不一樣。但在DevOps模式下，編寫的便是發佈的，由於開發人員在代碼被交給QA甚至到產品環境後，仍能夠繼續查看和訪問代碼。換句話說，開發人員擁有從建立到實現的整個交付過程的代碼全部權。部署
更多相關的工做。開發人員和大多數人類同樣，在真實世界中相關的工做中更容易獲得知足感。由於在傳統組織中的開發人員是孤立的，他們常常虛構用戶場景來模擬問題。當出問題的時候他們只能儘可能模擬接近這個問題。在DevOps模式中，場景是真實的。環境是通過負載測試的，好比，在軟件被放入產品環境以前會測試是否能正確工做。另外一個例子是測試腳本自己能夠測試產品你環境，而不只僅是模擬環境。將測試結果分享給開發人員，給予了開發人員查看在真實條件下他們編寫的代碼的性能的機會。get
已經實現DevOps意味着什麼
可能你的組織已經採用了DevOps模型。有三個問題可讓你清楚的瞭解DevOps的實行狀況：同步
你做爲一個開發人員，可以實時獲取故障信息嗎？團隊協作
產品環境中是否使用了開發團隊的測試及其它工具來驗證產品環境是否能正常工做？
做爲開發人員，你是否視網絡團隊爲你的合做夥伴？
若是這些回答都是「否」，那麼你並未真正實現DevOps。有一些建議能夠改進該狀況。先從工具提及。DevOps是文化和流程高於組織，工具能夠幫助執行最佳實踐。特別是跨團隊共享故障信息。這要求在軟件中添加更多的檢測信息以便查看軟件在QA及產品環境中的執行狀況，而不只僅是開發環境中。這些代碼會捕獲錯誤，檢查系統參數，報告功能超時，以及返回程序執行期間的其它值，並將其寫入到日誌文件中。
在孤立的環境中，一旦代碼被髮布到產品環境中，開發人員每每不能再查看這些日誌文件。在DevOps世界中，開發人員能夠查看任意環境中的日誌文件，不論是開發環境，QA環境仍是產品環境。這樣不只能夠快速修復缺陷，也能夠避免一樣的缺陷出如今未來的發佈中。這使得開發自身對業務能更快速，更具響應性，把敏捷質量引入到敏捷開發中。
打破舊習慣
DevOps也要求打破舊習慣。好比天然傾向是軟件bug數量做爲衡量質量的方式。但修復單個bug並不意味着能更快的建立無bug的軟件。更好的衡量方式是處理bug的流程。換句話說，整個流程中是那個環節引入這個bug的？例如，是由於開發人員本地的構建環境與QA環境或產品環境不一致？或者是代碼行爲之因此在不一樣環境中表現不一致是由於某些環境中沒法顯示某些東西？
除非代碼版本是跨環境緊密同步的，並且這些環境也是緊密同步的，不然很難搞清楚一個問題究竟是個邏輯問題仍是數據問題，抑或環境問題，或者其它問題。而工具可以保證其一致性。即工具能自動的將一樣的代碼一次性部署到多個環境中。
合做夥伴或譴責者？
開發人員須要作的最大改變可能就是與其餘團隊成員要有平常互動。開發人員是是主動解決軟件問題（好比經過平常監控操做日誌），仍是等待問題報告給他們？當有問題時，又是如何被解決的？團隊成員是合做夥伴仍是譴責者？
不少都取決於領導力。無論管理團隊如何說教DevOps願景，請以身做則，提供必要的培訓和支持，獎勵開發人員的團隊貢獻，而不只僅是技術能力。DevOps須要一個樂隊指揮。即便當前工做並非你的工做領域，你也應當接受它。實現DevOps環境須要理解什麼對於管理是重要的；是否是發佈更快了？是否是質量更高了？是否是開發人員對他們的代碼更負責了？這些都與DevOps環境的方式有關。
Neil Garnichaud是SmartBear公司的Host Solutions Business經理，負責產品開發及軟件研發。