一千萬個為什麽

搜索

從6個月到16秒? DevOps加速DORA和Puppet Labs的DevOps報告中的數據加速



Puppet Labs的年度DevOps報告是一個非常好的和有代表性的信息來源,AFAIK。事實上,有了Kim Gene,他們就是我會說的行業權威。

現在我對今年的報告中的以下數據有疑問(第21頁)。

我們可以乘以2016年和2017年的數據嗎?

例如,花時間進行更改。

2555x440=1124000 # more than a milion times faster?

那麽這是否意味著,如果在2015年花了6個月的時間(比如實時180天,即4320小時)來提供bug修復,那麽

  • 在2016年花了不到2個小時,
  • 和2017年, 16秒

速度傳送速度現在是否真實? 2014年,管理層甚至對30倍的加速都持懷疑態度。現在我很懷疑。

Question: this must be absolute minimum values for very lightweight microservices. That is, as the bugfix commit arrives..

  • 你真的從這一刻算起
  • 你沒有編譯步驟
  • Docker鏡像非常小
  • 您的基礎設施非常快(或者,您可以獲得的速度最快)。

對?

enter image description here

轉載註明原文: 從6個月到16秒? DevOps加速DORA和Puppet Labs的DevOps報告中的數據加速

一共有 1 個回答:

我不會那樣計算它。這並不一定意味著變更集的驗證時間正在減少很多。

驗證過程本身可以(現在也經常是這樣)處理管道,其中每個變更集的平均/有效驗證時間實際上可以減少到非常小的數量。

例如,處理管道可以同時處理多個變更集。如果您有,我們假設有60個建議的更改,其中每個更改都會觸及存儲庫中的不同文件,您可以將它們組合成等效的單個超級更改集,以觸及60個文件。然後,您可以通過驗證步驟來處理這個超級變更集,比如1h。如果驗證通過,即使實際驗證時間為1小時,您也可以獲得x60的加速因子和每個1分鐘更改的有效驗證時間。當然,如果驗證失敗,您將失去一些加速,並且您需要執行平分來識別出現故障的變更集,但這是一個不同的故事。

或者,您可以通過並行執行60個1小時驗證來獨立驗證每個變更集。同樣有效的驗證時間,但是驗證資源使用量更高。

我想這一點是有辦法構建處理管道,這可以大大減少有效的每個變更集的驗證時間,並且仍然保持非常大規模的項目敏捷。

還有一點需要考慮的是分支策略。這6個月不是實際的驗證時間。大部分時間僅僅是通過分支spagetti 進行導航並與集成地獄,只是為了將修補程序傳播到正確的運輸分支 - 瀑布式開發模型的影響這在當時被認為是常態。

今天CI/CD(正確的一個,而不是 CI劇院)和基於主幹的開發,可以消除所有浪費的時間/精力和側面步伐,從整合到後備箱裏的那一刻起,這種修復方式幾乎可以準備好交付 - 不會出現無法預測的大規模分支合並障礙。