一千萬個為什麽

搜索

什麽是'特征標誌切換'以及何時使用它們(或不)?



有一些關於 功能標記切換 的問題,例如:

My questions:

  • 實際上,“功能標誌切換”(在DevOps環境中)是什麽?
  • 他們為什麽使用?

轉載註明原文: 什麽是'特征標誌切換'以及何時使用它們(或不)?

一共有 2 個回答:

無需重復 https://martinfowler.com/articles/feature-toggles.html,因為這是關於什麽功能標誌切換的深入解釋。我將專註於DevOps方面。

根據PuppetLabs編寫的 2014年DevOps報告狀態,有四個衡量IT績效的主要指標:

  • 更改時間
  • 發布頻率
  • 恢復服務的時間
  • 更改失敗率

這些也有助於整體組織績效。所以這意味著如果您的IT在這些指標上表現出色,您的底線會獲得更多$$$。

Continuous Delivery is enabled by these metrics, and has been described in depth in the book Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble.

持續交付的背景下,有一個重要的區別,它與持續部署。這就是決定何時(向客戶)發布功能的發布的決定。

保持變更的規模較小,並將功能標誌切換關閉的生產系統部署(復制代碼)半成品功能可縮短更改提前期

當功能最終完成時,執行發布是業務決策。也許某個新功能的發布需要與某個市場營銷相匹配,或者與該移動應用中的某個功能相關的另一部分業務發布。

可以使用A/B實驗向客戶群中的一部分或特定人員發布功能,甚至直接發布到全面可用性(GA)。盡管向GA發布通常只有在確定該功能按預期工作後才能完成。有人可能會認為這實際上會影響發布頻率

releasedeploy 的解耦幾乎不可能在沒有功能標誌切換的情況下實現。

很自然,當不需要進行任何部署來關閉功能關閉時,則恢復服務時間會大幅降低。

通過使用向客戶群中的一小部分發布功能的功能標誌,更改失敗率指標也可以顯著提高。


因此,一種稱為特征標誌切換的簡單機制可以提高IT性能,進而提高整體組織績效。

Flickr (關於該主題的最早公開帖子)以及 Etsy的。但許多其他人已經采用這種做法並詳細討論了它,例如著名的

Etsy的展示了他們的內部工具來管理功能標誌,稱為Catapult,在多個演示文稿中找到圍繞網絡。 Intuit發布一款名為Wasabi的開源工具,可幫助管理功能標誌。

Ken Mugrage posted an interesting comment below my question, with a link to an illuminating explanation of "Feature toggles", with a summary of it like so:

功能切換是一種強大的技術,允許團隊在不更改代碼的情況下修改系統行為。它們屬於各種使用類別,在實施和管理切換時將這種分類考慮在內是很重要的。切換會引入復雜性。我們可以通過使用智能切換實現實踐和適當的工具來管理切換配置來保持復雜性,但我們也應該旨在限制系統中的切換次數。

上述總結不僅有助於理解這是什麽,而且還包含一些解釋為什麽使用的示例。在進一步消化之後,似乎“特征切換”和“特征標誌切換”幾乎是彼此的同義詞。

但是,對問題(問題)的解決方案(回答)會改變問題......有人可能會問有關的問題,例如:

  • 使用它們有什麽優點/缺點?這是一個強大的概念,但如果不是明智地使用(並且適當地保證)......也是一個可怕的概念。
  • 什麽可能是一些例子(好的和壞的)在哪裏使用?我可以想到其中的很多,其中一些我很早以前就已經使用過(從DevOps開始甚至是一件事)。