目錄

模式一

模式二

模式三

本文摘抄自：DevOps的概念與實踐 

模式一

敏捷開發模式

 通常，在軟體開發專案中，開發會用完所有計劃的時間用於開發功能，這樣會導致無法充分解決IT運維的問題，這就是開發和IT運維以及次優結果之間的永恆的緊張關係的主要原因。後果可能很嚴重，比如：不適當的定義和指定環境，無法重部署，程式碼和環境的不相容等

按照敏捷的要求，在每個迭代結束後，我們就會發布能執行且可被部署的程式碼，通常時間為兩週。我們將修改敏捷迭代週期策略，不僅僅只交付能執行且可被部署的程式碼，同時在每個迭代週期的早期，還必須準備好環境用於部署這些程式碼。建立一個自動化的環境建立流程，這種機制不僅僅只建立生產環境，也包含開發和QA環境。通過使環境早期即可用，開發和QA可以在統一穩定的環境中執行和測試程式碼，從而控制不同環境之間的差異。通過保持不同階段儘可能小的差異，在生產部署之前，我們就能發現並修復程式碼和環境之間的互操作性問題。

理想情況下，部署機制是完全自動化的。

模式一：儘早讓環境統一併可用，即將IT運維嵌入到開發中。

模式二

模式二的一個重要要素就是縮短和放大反饋迴路，使得開發更貼近客戶體驗（包括IT運維和終端使用者）

 模式二：將開發嵌入到運維中。

將開發嵌入到IT運維的問題升級鏈中，可以將他們放在三級支援中，甚至使開發對整個程式碼的部署成功負責。要麼回滾，要麼修復缺陷，直到服務恢復。

讓開發看到他們的工作和變更帶來的下游變化，激勵開發以IT運維的視角來解決問題，從而達到一個全域性的目標。

模式三

不夠規範！

定義可重用且可跨多個專案的部署流程，敏捷方法裡有一個很簡單的解決方案：將部署的活動變成一個使用者故事。

例如，為IT運維構建一個可重用的使用者故事，叫做“部署到高可用環境”，這個使用者故事定義了明確的構建環境的步驟、需要多長時間、需要哪些資源等。這些資訊可以被專案經理用來整合部署內容到專案計劃中去。

認識到有些特定的軟體專案要求特別的環境，且不被IT運維官方支援，我們可以允許這些被生產允許的環境中的例外，但是被IT運維部門外面的人提供支援的。

環境標準化（可以減少生產差異、環境更一致、IT運維的支援和維護能力增加等），又能在允許的特殊情況下，提供業務需要的靈活性。