什麼是 DevOps?

最近常看到這個詞, 我查了一下.

  • DevOps(英文Development和Operations的組合)
  • 是一組過程、方法與系統的統稱,用於促進開發(應用程式/軟體工程)、技術運營和質量保障(QA)部門之間的溝通、協作與整合

它的出現是由於軟體行業日益清晰地認識到:為了按時交付軟體產品和服務,開發和運營工作必須緊密合作

傳統的軟體組織將開發、IT運營和質量保障設為各自分離的部門。在這種環境下如何採用新的開發方法(例如敏捷軟體開發),這是一個重要的課題:按照從前的工作方式,開發和部署不需要IT支持或者QA深入的、跨部門的支持,而現在卻需要極其緊密的多部門協作。然而DevOps考慮的還不止是軟體部署。它是一套針對這幾個部門間溝通與協作問題的流程和方法

DevOps的引入能對產品交付、測試、功能開發和維護(包括──曾經罕見但如今已屢見不鮮的──「熱補丁」)起到意義深遠的影響。在缺乏DevOps能力的組織中,開發與運營之間存在著信息「鴻溝」──例如運營人員要求更好的可靠性和安全性,開發人員則希望基礎設施響應更快,而業務用戶的需求則是更快地將更多的特性發布給最終用戶使用。這種信息鴻溝就是最常出問題的地方

以下幾方面因素可能促使一個組織引入DevOps:

使用敏捷或其他軟體開發過程與方法業務負責人要求加快產品交付的速率虛擬化和雲計算基礎設施(可能來自內部或外部供應商)日益普遍數據中心自動化技術和配置管理工具的普及有一種觀點認為,目前占主導地位的「傳統」美國式管理風格(「斯隆模型 vs 豐田模型」)會導致「煙囪式自動化」,從而造成開發與運營之間的鴻溝,因此需要DevOps能力來克服由此引發的問題。

DevOps經常被描述為「開發團隊與運營團隊之間更具協作性、更高效的關係」。由於團隊間協作關係的改善,整個組織的效率因此得到提升,伴隨頻繁變化而來的生產環境的風險也能得到降低

DevOps將顛覆未來IT人角色

可達到軟體持續交付的開發方法DevOps(來自Development和Operations 2個字的縮寫組合),這也是不少大型雲端服務能夠快速版本更新的秘訣之一,如Flickr就運用了DevOps開發方法來加快服務改版速度,甚至一天可以因功能需求,發布10次小改版

DevOps開發方法藉由將各開發階段自動化以及訊息公開,幫助企業軟體研發相關部門,解決傳統流程端對端(End to end)所產生訊息不對稱,以及協作不順暢的問題,並且自動化開發流程的每個階段,進而提升軟體交付的速度。

DevOps開發方法的觀念及工具,可以做到快速的實作、快速的部署、快速的完成軟體週期以及快速的得到用戶回饋

靠IT讓開發團隊與營運團隊的密切合作,從而弭平文化鴻溝是重要的

DevOps開發方法是敏捷(Agile)以及精實(Lean)開發概念的延伸,有別於傳統開發流程

DevOps開發方法打破每個獨立的階段,從需求分析、系統設計、程式開發、安裝測試、後續維護再回到第一階段,形成一個封閉迴圈

DevOps開發方法要開發人員持續改善並整合不同的階段,加以組織過去任務所發生的事,開發人員需要自動化的工作流程,自動化開發周期的每一個階段,不僅需要自動化測試,還要自動化部署,且提供自動化的數據給所有參與的人,讓所有人可以合作

團隊的組織架構必然需要改變,開發和維運團隊需要更緊密合作,這是第一點。第二點是,開發周期循環變快,團隊的人需要不同的技能,並整合這些能力,甚至有一些公司是沒有開發和維運團隊之分

DevOps是來自Development和Operations這2個英文字的縮寫組合,顧名思義,DevOps開發方法最主要改善的是開發團隊以及維運團隊的關係

  • 傳統的端對端開發流程(End to end)概念是指,每一個團隊都有的獨立功能,開發團隊專注軟體開發,維運團隊做軟體部署,但是當功能被明顯切割,必定會影響團隊間訊息的同步,例如維運團隊無法確切掌握軟體執行的環境,當開發團隊遞交的軟體不符合部署環境,或是更改軟體規格時,維運團隊就必須把軟體退回給開發團隊,這樣一來一往耗費時日,軟體交付速度便會受到嚴重影響

因此如果導入DevOps開發方法中的自動化部署,便可由開發團隊設定部署環境,由工具做自動化部署,減少手動以及傳遞的時間,且可以避免人為錯誤,改善軟體交付

我覺得這些觀念都可讀但跟實際狀況都不會一樣. 這比較像是專案管理的新方式.  我好奇業界那家工作裡跟你講這個工作概念? ; 不過 R&D 和市場運營是有一些問題, 但各家各產品情況都不一樣, 不能一概而論.  這個DevOps, MMOPRG業界有在用嗎? 我懷疑. 但某些趕趕趕改改改的案子,搞敏捷開發的案子應該可用吧. 我會多留意這DevOpe工作方式的發展.

  • How much is culture and change part of DevOps?

To me, it’s 90% about cultural change, 10% about the technology. However, my perspective is shaped by my own experiences with software development and the conversations I have had over the past 15 years. Yes, absolutely, most of those conversations start with a technical problem. The one I reference a lot is a conversation I had with a friend who is an engineer at a closed source company. She was remarking that she wished she had even the possibility of using a continuous integration (CI) system like Jenkins at her workplace, but it would take forever to get it approved. But then she went on to remark that even if she did get it approved, she might aggravate her boss who told her that it wasn’t a priority, and she was concerned about the implications behind that. So it doesn’t matter what tools are on the market, or whether they are free or paid—if the overall culture of your company does not consider internal process improvement as a priority, then there is not a lot any tool is going to do for you.

  • What advice would you give to an engineer working in a DevOps environment?

Keep learning, keep being curious, keep questioning how things work. If you find yourself upset with the status quo, do something about it.

這短片也說明很清楚

Advertisements
發表留言

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s

%d 位部落客按了讚: