一千萬個為什麽

搜索

哪些方法可以將發布與部署分開?



持續部署的一種方法是將部署與發布分離,即部署更新而不立即激活更改。

I know that can be used for this, but I'm wondering if there are other techniques for "non-features".

例如,你會為bug修復建立一個功能切換嗎?可能不會,有人可能會說bug應該盡快部署,因為它只會變得更好。在修復程序發布後,我確定不想再將其關閉。 但是這是怎麽回事?您想以受控方式發布這可能是一個有風險的變化。如果有 意想不到的副作用,能夠回滾它是很好的。那麽,每個變化的特征標誌?

而視覺變化呢?例如,你可以在CSS中實現類似於功能標誌的東西嗎?它有意義嗎?

轉載註明原文: 哪些方法可以將發布與部署分開?

一共有 2 個回答:

對於網絡應用程序類別中的軟件,根據您的基礎設施/托管服務提供商,這種解耦可能可以將傳入流量切換到(或將其分開)sw的不同部署版本,實際上涵蓋了任何你提到的變化:錯誤修正,視覺效果等

這種支持通常不需要功能切換。無論應用程序是單一的還是拆分為微服務,它都可能適用。

例如,Google的 App Engine Paas產品可支持流量分割和遷移。

拆分流量

您可以使用流量拆分來指定百分比分配   流量跨服務中的兩個或更多版本。拆分   流量允許您在版本之間進行 A/B測試   並在推出功能時控制節奏。

遷移流量

流量遷移在版本之間切換請求路由   在您的應用程序的服務中,移動一個或多個流量   版本轉換為單個新版本。

盡管單塊可能僅限於交換機,但使用微服務體系結構,您可以拆分每個提供服務的節點的部署池(即。pod)。然後在池的子集中激活部署新更改的產品,並仔細監控它;您甚至可以選擇要將更改部署到哪個池中,例如,激活15%流量的更改。您可能會在文獻中找到稱為“滾動更新”的功能。