Microsoft 在為生產環境提供高度可調整的服務方面擁有數十年的經驗。 隨著 Microsoft 服務和環境的擴展，其交付實踐也隨著時間的推移而演變。 許多 Microsoft 客戶也採用了這些高效的交付實踐並受益於這些高效的交付實踐。 下列核心 DevOps 原則和程式可套用至任何新式軟體傳遞工作。
為了實施 DevOps 交付流程，Microsoft 採用了以下計劃：
- 將組織思維和節奏集中在交付上。
- 組建自主、負責任的團隊，負責擁有、測試和交付功能。
- 右移以測試和監控生產中的系統。
專注於交付
更快的運輸是組織和團隊可以輕鬆衡量和欣賞的明顯好處。 典型的 DevOps 步調涉及短期 衝刺 週期，並定期部署到生產環境。
由於擔心短衝刺會缺乏產品穩定性，一些團隊在衝刺週期結束時通過穩定期來彌補。 工程師希望在衝刺期間發布盡可能多的功能，因此他們產生了測試債務，他們必須在穩定期間償還這些債務。 在衝刺期間有效管理債務的團隊接著必須支援累積債務的團隊。 額外成本通過交付管道傳遞並影響到生產。
取消穩定期後，團隊管理債務的方式迅速改善。 累積債務的團隊不必將關鍵的維護工作推遲到穩定期，而是必須在下一個衝刺中趕上他們的債務目標。 團隊很快就學會了在衝刺期間管理他們的測試債務。 當功能經過驗證且符合部署成本時，功能才會推出。
完全自動化管道
團隊可以立即獲得的大部分改進是將從程式碼儲存庫到生產環境的管道完全自動化。 自動化包括 具有持續整合 （CI）、自動化測試和 持續交付 （CD） 的發行管道。
團隊可能會避免部署，因為它很難，但部署的頻率越低，就越難。 部署之間的時間越長，堆積的問題就越多。 如果程式碼不是最新的，則有部署債務。
透過頻繁部署，更容易在較小的區塊中工作。 事後看來，這個想法似乎很明顯，但在當時似乎有悖常理。 頻繁的部署也會激勵團隊優先建立更有效率、更可靠的部署工具和管道。
使用內部工具
Microsoft 會使用他們建置的發行管理系統，並將其運送給客戶。 單一投資可提高團隊生產力和 Microsoft 產品。 使用輔助系統會吸走開發和交付速度。
團隊自主權和問責制
沒有特定的關鍵進度指標 （KPI） 可以衡量團隊生產力或績效，或功能是否步入正軌。團隊需要能夠管理自己的計劃和待辦專案，同時找到與組織目標保持一致的方法。
直接與團隊溝通以追蹤進度非常重要。 工具應該促進溝通，但對話是最透明的溝通方式。
排定功能優先順序
一個重要的目標是專注於提供功能。 排程可以評估在給定時間段內可以合理完成多少團隊和個人，但有些功能會更早交付，有些功能會更晚推出。 團隊可以排定工作的優先順序，以便最重要的功能投入生產。
使用微服務
微服務 提供各種技術優勢，可改善和簡化交付。 微服務也為團隊所有權提供了自然的界限。 當團隊對微服務投資擁有自主權時，他們可以優先考慮如何實施功能和管理債務。 小組可以專注於版本管理等因素的規劃，而不受相依於微服務的整體服務的影響。
主要工作
工程師過去在不同的分支機構工作。 每個分支的合併債務不斷增長，直到工程師試圖將其分支整合到主分支中。 團隊和工程師越多，整合就越大。
為了更快、更連續、更小塊地進行整合，工程師現在在主分支中工作。 遷移到 Git 的一個重要原因是 Git 提供的輕量級分支。 內部工程的好處是消除了深層分支層次結構及其浪費。 過去花在整合上的所有時間現在都投入到交付上。
使用功能旗標
某些功能尚未完全完成短期衝刺部署，但仍可從生產環境中的測試中獲益。 團隊可以使用 功能旗標 合併和部署此程式碼，為特定使用者開啟該功能，例如開發團隊或一小部分早期採用者。 功能旗標可控制曝光，而不會冒整體使用者群出現問題的風險，並可協助小組決定是否以及如何完成功能。
生產環境中的測試
在生產環境中進行測試向右轉移有助於確保生產前的測試有效，並且使生產環境準備好以應對不斷變化的環境和部署需求。
儀器測試和指標
無論應用程式部署在何處，監控所有內容都很重要。 儀器化不僅有助於識別和解決問題，還可以提供關於使用方式及未來擴充計畫的珍貴研究資料。
測試復原模式
複雜部署的風險是 串聯失敗，其中一個元件失敗會導致相依元件失敗，依此類推，直到整個系統崩潰為止。 請務必瞭解 單一失敗點 （SPOF） 的位置以及如何緩解它們，並測試緩解程序，尤其是在生產環境中。
選擇正確的指標
設計指標可能很困難。 一個常見的錯誤是包含太多指標，以避免遺漏任何內容。 但這可能會導致忽視或不信任不滿足特定需求的指標的價值。 相反地，Microsoft 小組會花時間來判斷衡量成功所需的數據。 團隊可能會新增或變更計量，但從一開始就了解目的有助於該過程。
除了指標的基礎之外，團隊還會考慮他們需要指標來衡量什麼。 例如，使用者增益的速度或加速可能是比使用者總數更有用的指標。 指標因專案而異，但最有幫助的是那些有可能推動業務決策的指標。
使用指標來指導工作
Microsoft 包含最高領導層級審核的指標。 每六週，組織就會展示他們在健康情況、業務、場景和客戶遙測方面的表現。 組織與高階主管及其團隊討論指標。
整個組織的團隊會檢查參與的使用者指標，以判斷其功能的意義。 團隊不僅推出功能，還會查看人們是否以及如何使用這些功能。 小組會使用這些計量來調整待辦專案，並判斷功能是否需要更多工作才能達到目標。
投遞指南
- 從 A 到 B 從來都不是一條直線，B 也不是終點。
- 總會有挫折和錯誤。
- 將挫折視為改變策略以完成流程特定部分的學習機會。
- 隨著時間的推移，每個團隊都會透過建立經驗並進行調整來滿足不斷變化的需求來發展其 DevOps 實踐。
- 關鍵是專注於向最終用戶和交付過程本身提供價值。