一千萬個為什麽

搜索

“環境管理”如何在DevOps世界中發揮作用?



今天我有一些非常有趣的談話,關於環境管理在遵循DevOps實踐的團隊中的作用。 環境管理器的傳統角色是:

全面負責在軟件開發生命周期的所有階段協調多個團隊和組件,以確保及時交付和提供已知的一套軟件版本。

我相信,在一個跨DevOps實踐的跨職能敏捷團隊中,這些責任屬於整個團隊,最終對產品負責人作為業務代表負責。

In short, my question is who is... responsible for Environment Management in a team following DevOps practices, i.e., one that does not have an external Environment Manager function available to them.

轉載註明原文: “環境管理”如何在DevOps世界中發揮作用?

一共有 2 個回答:

我從來沒有聽說過“環境經理”。另一方面,發布管理歷來被整合到一個人或團隊中。

在DevOps模型中,發布管理更多地是來自Dev和Ops的元素所支持的流程。高度“DevOps成熟度”的組織並沒有真正具有獨特的版本管理事件 - 發布行為被烘焙到持續傳輸管道中(請參閱“推送綠色”什麽是“推綠色”?

OP也可能指的是配置管理,其中特定於環境的配置是手動管理的,或者是由像Puppet或Chef這樣的工具管理的。這項工作傳統上是Ops管理的任務,具有較高成熟度的組織通過代碼處理。 Dev和Ops可以共享責任,或者可能有專門的SRE團隊處理配置管理。

我看到了三種方式來處理這種需求。

  1. 該軟件聲明它的依賴關系,並在每個依賴關系下以獨立於其他版本的正確版本發布。例如,如果兩個版本的相同依賴關系對於數據庫訪問不兼容,則可能會產生問題,並且需要上述系統以確保只將兼容版本部署到環境中,實現它的方式可能因工具而異,並且相當困難為了得到它。

  2. 該軟件聲明其依賴關系,並且如果目標環境上的一個依賴項的當前可用版本不匹配,那麽deploy會停止並保留實際版本的軟件。然後,團隊需要與依賴團隊進行協調,以了解他們何時能夠部署。主要缺點是這可能會導致發行版本的延遲。這裏再次實現它的方式可能會因工具而異。

  3. 由每個團隊成員組成的跨團隊,負責協調版本和發布。這有助於在正確的時間獲取內容,但不會強制執行任何控制。

在我看來,最好的設置是2 + 3以上,以處理任何錯過依賴的問題,同時在單獨的團隊之間實施通信並允許發布與多個版本的依賴關系兼容。這種需要保持跟蹤這種行為改變,以消除不再需要的不需要的舊API處理。