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