記DevOps的一次理解

2021-10-08 06:59:48 字數 1461 閱讀 1280

這段時間寫了一些 《從零搭建devops平台環境》 相關的文章,後續也寫了一些其他的工具的,但是都沒有發出來。因為這段時間我在寫這些的時候,同時也在整理資料,重新梳理一下devops,也理一下我們的devop的現狀。逐漸有了一些其他的想法,對於工具鏈的使用,工具鏈搭建的越來越多難道就是devops了麼?

devops是敏捷開發的延續,繼承自敏捷軟體開發,devops 的出現是為了應對敏捷方法所帶來的軟體開發速度和生產力增長。敏捷文化和敏捷方法在最近十年的發展,呼喚乙個更適合端到端軟體交付生命週期的整體方法。 那麼我們是不是可以理解為: devops是為了實現敏捷開發,一切為了敏捷而做的事情都是devops?

那麼因此也引出來乙個概念:敏捷開發。那麼什麼是敏捷開發呢?

敏捷開發是許多迭代和增量軟體開發方法的總和。最流行的敏捷方法包括scrum、看板、規模化敏捷框架(safe®)、精益開發和極限程式設計 (xp)。敏捷開發的方法是多種多樣的,但所有的方法都有著共同的願景和核心價值觀-敏捷宣言。

那麼devops是不是就是所有敏捷方法的概括,然後增加了一些擴充套件實踐呢?

可能會有同學覺得,這些還是在講devops的理論,很虛。

但其實所謂的devops落地本質上就是和開發找bug一樣,發現問題、定義問題、提出解決方案、然後不斷實驗該方案的乙個迴圈過程。永遠不會存在乙個通用的解決方案,重要的是積累定義問題的經驗,培養解決問題的能力。

在寫這篇文章之前,我翻了很多其他企業實踐的案例,有套路,有姿勢,由大而全,有小而精,但無一不是根據自己公司的業務場景去發現問題,找到自己實踐過程中的痛點然後去逐步解決的。這是乙個必然的過程,可能有些在我們實施的過程中也會出現,可能有些在我們看來根本就不是問題。

devops的工具鏈有很多,甚至我們可以說,只要為了解決軟體開發過程中的問題的都屬於devops工具鏈,如果按照這個來衡量devops平台的搭建那可能真的遙遙無期了。因此這一篇也算是對我之前發的所謂的《從零搭建devops平台》的乙個結束。

這是我自己以前整理的一些devops工具鏈

關於devops的實踐,有一些標準化的演進路線

有人總結了乙個實踐套路

三個姿勢:

五個步驟:

招商銀行案例

攜程案例

美團案例

最後放一張,我理解的全流程

記一次的使用

將jsp拆分frame框架,因為採用了第一種方式,一直在考慮用jquery非同步請求獲取資料,總是但不到效果,終於在js寫吐的時候選擇了第二種方式。參考網上的使用,大多是下面這個樣子,如果涉及靜態頁面之間定位,是沒有問題的 href 為目標頁面 通過target定位到frame views main...

記一次除錯

這是我最近幾個月來遇到的最棘手的乙個問題 昨天花了4個小時找出第一層次的原因 這個糾結啊,本來和老婆說好準時下班回家吃飯的,結果被這個問題拖了老久。這是乙個gradle的plugin,用來resolve公司內部的dependency的,弄完了跑測試專案的,拋乙個npe,而且npe還不在自己的 裡面。...

記一次 EqualsAndHashCode的疑惑

lombok的使用真的是讓開發人員欲罷不能,乙個 data不管有多少屬性全部搞定,以後加字段也不用從新生成get和set方法。不過這裡還是有乙個小坑需要注意一下,舉個例子 public class equalsandhashcodetest data noargsconstructor access...