這是Puppet報告的走過的第九個年頭，本次報告基於對2400名IT、開發、資訊保安行業的技術人員的調研，著重勾畫了DevOps狀態的兩大趨勢：平臺模型、需求變更的管理。
多年來，我們已經證明了DevOps實踐會帶來更好的績效和組織成果，也學習並分享了組織的發展，以及如何更快地釋出更好的軟體。
看到顯著進展的同時，我們也看到大多陣列織都在努力超越他們進階的中間階段。這些團隊可能是較難擴充套件DevOps工作方式的開發團隊、運維團隊和安全團隊。
然而，有些組織確實取得了成功。他們擴充套件了DevOps超出最初早期採用團隊的實踐，繼續在整個組織內不斷髮展和改進。是什麼造成了這種區別？成功的組織實施的更深層次結構的變化。今年的DevOps調查顯示可以產生優異結果的結構變化：將DevOps原則應用於軟體交付和變更管理。
當組織成功地建立了一個平臺用於支援應用程式開發的模型時，就可以提高他們的變更管理效率，並實現DevOps計劃的目標：更快、更高效、更容易地交付質量更好、更安全的軟體。
為何是研究平臺模型和需求變更管理這兩個方向呢？
平臺模型是相當有效地賦能應用團隊的新方法。一旦正確實施，它就會起作用，結果就是更快、更有效地交付高質量的軟體、滿足組織的業務需求——大規模應用也同樣如此。
需求變更的管理是常見的拖慢軟體釋出速度、阻止企業實現目標的因素，高效的需求變更管理提高了組織在業務所需級別上按時、保質、安全地釋出軟體的能力。
報告中，我們在調查中討論了發現的各種變革管理各種方法，並展示如何應用DevOps原則把變更管理從阻礙變成更快、更安全的軟體交付的方法。
將DevOps擴充套件到Dev和Ops之外
在任何組織中，通過軟體創造價值不僅僅依賴於開發人員和運維人員之間的良好協作。幾乎所有相鄰的業務功能最終都是軟體過程的一部分，這些功能需要與技術交付團隊一起發展。
敏捷曾經是工程師的專屬財產，但現在已經不是了。這些年來，從軟體團隊擴充套件到財務、人力資源、執行領導團隊等等。我們希望DevOps原則和實踐除了最初開始與他們合作的開發和運維團隊，在其他領域也會繼續傳播，比如DevSecOps、FinOps，可能還要其他我們沒見過的新的表現形式。
也許再過幾年，“DevOps”這個詞已經是老生常談——甚至逐漸消失——因為有那麼多的人和組織完全採用了DevOps的協作原則：溝通、小批量迭代、反饋迴圈、持續學習和改進。
運用內部平臺團隊擴充套件DevOps實踐
DevOps從根本上講就是讓人們能夠彼此合作，為了共同的商業目標而奮鬥。這必然包括團隊使用的過程和工具，但是還需要經常進行對話來解決組織內部阻礙良好發展的結構性問題，讓工作能夠自由流動和持續改進。
儘管DevOps的實踐已經被很好地理解和採用了十年。在這場運動中，我們仍然看到大多陣列織都在努力將DevOps擴充套件到少數成功領域之外。DevOps往往無法進一步擴張的一個原因是，大多數企業的結構造成了激勵不一致和缺乏責任感，這使得合作無法推進。
DevOps演化模型
單獨採用一組實踐的團隊不能進一步推進DevOps 的進階，必須進行相應的結構更改，以優化團隊的工作方式。 DevOps演化模型表明，在沒有團隊外部的人工批准的情況下，在第4和第5階段之前，組織不會在自助服務和安全整合方面取得進展（第三階段）。
第三階段是一個關鍵的趨同點——信任已經在第一階段和第二階段建立了；團隊獲得了更多的自主權；部署不再是一場災難。 在這一點上，團隊可以擴充套件他們的新合作方式，跨越更多的功能邊界，超越Dev和Ops。
在第3至第5階段，我們看到了一刀切的規則和流程的鬆動，其基本重點是自動化。在這些階段，自動化已經超越了為單個個體或團隊解決區域性問題的範圍，擴充套件到了更獨特、更高的目標：為企業創造價值。
這就是擴大DevOps實踐的含義： 通過授權個人和團隊，依靠他們的知識和經驗以及自動化，可以在整個組織實現大規模優化。現在您可以集中精力消除多個交付流中的浪費，並幫助企業實現其目標。