檢視 DevOps 的原始碼

'''DevOps'''（'''Dev'''elopment 和'''Op'''erations 的混成詞）是一種重視「軟體開發人員（Dev）」 和「IT 運轉去維技術人員（Ops）」 溝通合作的文化、運動抑是慣例。通過自動化「軟體交付」和「架構變更」的流程，來予構建、測試、發佈軟體會當閣較緊、頻繁佮可靠。

傳統的軟體組織將開發、IT 運作品質的保障設為各自分離的部門，佇這款的環境下按怎採用新的開發方法（譬如講扭掠軟體的開發啊）， 是一个重要的課題。照對進前的工作方式，開發和部署，無需要 IT 支援抑是 QA 深入的跨部門的支援；這馬煞需要極其實密密的濟部門協同運作。而且 DevOps 考慮的猶毋但是軟體部署，伊是一套針對這幾个部門溝通佮協同運作問題的流程佮方法。

需要頻繁交付的企業可能閣較需要著 DevOps 有一个大致的了解。Flickr 發展了家己的 DevOps 能力，使會當支持業務部門「逐工部署十擺」的要求 ─ ─ 若是一个組織欲生產面向真濟種使用者、具備多樣功能的應用程式，其部署周期必須會真短。這種能力嘛予人號做是持續部署，並且經常佮精益創業的方法來聯絡。對二空空九年起，相關的工作群組、專業組織和部落格快速湧現。

DevOps 的引入會當對產品交付、測試、功能開發佮維護（包括講 ─ ─ 捌罕見但如今已經沓沓看看無鮮的 ─ ─「熱修補程式」）起到意義深遠的影響。咧欠缺 DevOps 能力的組織內底，開發佮運營之間有存在的資訊「鴻溝」─ ─ 譬如講運營的人員要求閣較好的可靠性佮安全性，開發人員希望基礎設施回應較緊，業務使用者的需求是更加緊將閣較濟特性發布予終端使用者使用。這種資訊鴻溝就是上捷出問題的所在。

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

一 . 使用扭掠或者是其他軟體開發過程佮方法二 . 業務負責人要求加快產品交付的速率三 . 虛擬化佮雲端運算基礎設施（可能來自內部抑是外部供應商）日益普遍四 . 資料中心自動化技術佮組態管理工具的普及五 . 有一種觀點認為，目前占主導地位的「傳統」美國式管理風格（「 斯隆模型 vs 豐田模型」）會致使著「煙筒式自動化」，自按呢造成開發佮運維之間的鴻溝，所以就需要 DevOps 能力來克服所致引發的問題。

DevOps 不時咧描述講「開發團隊佮運維團隊之間閣較鬥陣運作性、閣較高效的關係」。 因為團隊間協同運作關係的改善，規个組織的效率因此得著提升，伴隨頻繁變化而來的生產環境的風險嘛會當得著降低。

==對應用程式發布的影響==

佇足濟企業內底，應用程式發布是一項牽涉真濟个團隊、壓力足大、風險足懸的活動。毋過佇咧具備 DevOps 能力的組織內底，應用程式發布的風險足低，原因如下：

'''減少變更範圍'''
: 佮傳統的水沖式開發模型相比，採用迵天代式開發意味著閣較捷的發佈、逐改咧發布包含的變化閣較少。因為部署定定咧進行，所以每一擺部署對生產系統造成誠大的影響，應用程式會滑溜的速率沓沓仔成長。

'''加強發布協調'''
: 靠強有力的發布協調人來彌合開發佮運維之間的技能鴻溝佮溝通鴻溝；用電子的資料來表示、電話會議、即時訊息、企業門戶（wiki、sharepoint）等協同運作工具來確保所有相關人員理解變更的內容閣全力合作。

'''自動化'''
: 大的部署自動化手段確保部署任務的會當重複性、減少部署脫箠的可能性。

==現狀==

真濟組織將開發佮系統管理來分做無仝的部門。開發部門的趕動力通常是「頻繁交付新特性」，運作維部門是閣較關心 IT 服務的可靠性佮 IT 成本投入的效率。兩个人目標的不匹配，就咧開發佮運維部門之間造成鴻溝，對遐減慢矣 IT 交付業務價值的速度。

* 開發人員定定無考慮家己寫的代碼會對運維造成啥物影響。𪜶咧交代碼進前，並無邀請維人員參與架構決策或代碼評審。
* 開發人員對組態抑是環境進行修改了後，不時都無及時佮運維人員的溝通，致使新的代碼袂當執行。
* 開發人員佇家己的機器頂頭修改組態，無記錄所有需要的步。欲揣著必要的組態參數，通常需要試看覓足濟無仝款的參數；佇得著一个會當做工課的狀態了後，往往足歹辨識出通過佗一寡上細步咧就會當到位應該狀態。
* 開發人員傾向著使用對快速開發的工具：對代碼修改較緊的回饋，閣較低的記持體消磨，等咧。這款的工具集佮運維人員面對的目標執行的時陣環境是蓋無仝款：後者對穩定性佮效能的要求較遠咧靈活性。
* 因為開發人員平常時使用桌面電腦，𪜶行對使用為桌面使用者最佳化的作業系統。生產環境的執行時系統通常攏執行侍服器作業系統上。
* 佇開發過程中，系統咧開發者的本地機器上執行。佇維過程當中，系統定定分布佇咧濟台侍服器頂懸，比如講 web 侍服器、應用侍服器、資料庫侍服器等等。
* 開發是由功能性需求（通常佮業務需求直接相關）驅動的。
* 運途是由非功能性需求（譬如講會當得著、可靠性、效能等）驅動的。
* 運維人員希望儘量避免修改功能，對而且降低滿足非功能性需求的風險
* 若拒絕細的修改，但是給定時間段內需要修改的總量不變，遐爾逐改變更加的規模就會變大
* 變更規模愈大，風險嘛愈大，因為其中牽涉著的區域愈濟
* 因為運維人員試避免變更加，新功能流入生產環境的速度所以予人延續，從而且延遲了開發人員將特性交付予使用者使用的速度。
* 運維人員可能對應用程式內底欠缺了解，對而難以正確的選擇執行的時環境佮發布流程。
* 開發人員可能對執行的時環境無了解，對而難以正確的對代碼進行調整。

==訴求==

* 閣較細、閣較頻繁的變閣較 ─ ─ 意味著閣較少的風險
* 予開發人員閣較濟控制生產環境
* 閣較濟應用程式為中心來理解基礎設施
* 定義簡潔明矣的流程
* 就算講伊可能地自動化
* 促成開發佮運維的協同運作一般來講，當企業希望共原本戇重的開發佮運維之間的工課移交過程變甲真順無礙，𪜶通常會拄著以下三類問題：

'''發佈管理的問題'''
: 足濟企業有發佈管理的問題。𪜶需要閣較好的發布計畫方法，毋但是一份共享的電子資料表示。𪜶著愛清楚了解發布的風險、依賴、各階段的入口條件，並確保各個角色遵守既定流程行事。

'''發布 / 部署協調問題'''
: 有發布 / 部署協調問題的團隊需要關注發布 / 部署過程中的執行。𪜶需要閣較好地佮蹤發布的狀態、較緊咧共問題升起來、嚴格執行流程控制佮細粒度的報表。

'''發布 / 部署自動化問題'''
: 遮的企業通常有一寡自動化工具，毋過𪜶猶需要以更加靈活的方式來管理佮驅動自動化工作 ─ ─ 無必要共所有的手工操作攏佇咧命令列中加以自動化。理想情形下，自動化工具應該會當佇非生產環境之下由非運轉來維人員使用。

欲開始最佳化發布流程，會當對問題辨識開始：看頂頭提著的佗一種問題佇咧你的團隊中具有上懸的優先級。

==發布協調人==

這是企業級 IT 組織內底一个新出現的角色，其主要任務就是協調安排將企業級軟體部署到預生產環境。著發布協調人的需求來自以下幾方面原因：

一 . 需要彌合開發佮運維的鴻溝二 . 基礎設施日依照變複雜：為著欲運維 web 應用，需要濟層基礎設施佮濟種平台三 . 發佈頻率上升（由余敏捷佮迵天代式開發的引入）
四 . 分散式團隊：位佇咧全球加一个地點的、包含外包人員的、透濫開發 / 測試 / 基礎設施的團隊發布協調人的角色（也予人號做部署協調人抑是整合協調人）源自發布管理抑是發布工程團隊。這个角色佮航空交通管制有一寡類似 ─ ─ 即時來協調無仝團隊的行動，有效使用共享的資源（空域、港路、跑道、航站門）， 達到組織的總體目標（安全起降）。

傳統意義上的發佈管理往往只關注軟體變更的計畫佮管理，發布協調則需要控制「將特定軟體變閣較發布至生產環境」的規个過程。這項工課需要系統的管理所有佮「將代碼構建並部署到生產環境」相關的技術任務，嘛予人號做「發佈工程」。

變更管理是佮蹤企業 IT 環境中各種變化 ─ ─ 毋管是應用程式抑是基礎設施的變化 ─ ─ 的基本原則。變更管理是 ITIL v 三的核心之一。

==參見==

* BizDevOps
* CI / CD

==參考文獻==

==外部連結==

* What Is This Devops Thing , Anyway ? ( by Patrick Debois , 二分之二千空一十 / 十二 )
* 捷伴行 Agile

'''產品'''

* IBM DevOps
* Nolio ASAP
* StreamStep SmartRelease
* The ControlTier Framework
* DevOps

[[分類: 待校正]]