一千萬個為什麽

搜索

如何說服開發人員開始使用功能標誌切換?



假設功能標誌切換是一個好主意,應該在開發人員編寫的代碼中實現。例如Etsy發誓他們是一個專業他們的文化的一部分

說服(並強制)開發者開始使用功能標誌切換的好方法是什麽?

有關功能標誌切換的更多信息,請參見問:如何使用功能標誌切換問:什麽是特征標記切換,並且在Pete Hodgson的關於此主題的文章中非常廣泛馬丁福勒的博客

轉載註明原文: 如何說服開發人員開始使用功能標誌切換?

一共有 4 個回答:

特性切換是高速開發中的常見做法,因為它們從版本脫離 development 。開發團隊可以將新功能“軟釋放”禁用狀態。這使得該功能可以隨時發布。如果該功能依賴於其他工作或準備工作,則無需等待主要版本投入生產。

就“說服”開發人員使用它們而言,這是為了提供它所提供的自由的練習。我的經驗是,這對開發人員來說不是一件難事。管理層往往不願嘗試新事物。嘗試這個:

  • 找到一個功能切換框架。管理/業務可能會更多 適合嘗試通用系統支持的內容
  • 從小開始。試用版中引入了切換系統,以顯示其實用功能。
  • 演示切換的A/B測試能力。為您的網絡農場的子集啟用切換​​,然後收集有關行為的指標。已經證明頁面布局上的微小差異對零售應用(例如Ebay,亞馬遜)的收入產生巨大影響

在理想的世界中,我認為你推出了一個新的構建和驚喜!沒有什麽變化。這是因為您的所有新功能都在開關關閉後關閉。

部署後,您確認您的部署服務仍然有效,電話不再響鈴(除非振鈴電話是您的目的,等等)等等。一旦您回到已知的穩定操作狀態,您就開始啟用和驗證您新部署的功能。

現在回答您的問題:您希望如何在一個團隊中工作,因為我們的網站和服務非常穩定,因此我們的用戶喜歡我們,因此我們的工作人員幾乎毫不費力。

這是我想要工作的團隊。

如果你願意,你可以在這裏停止閱讀。

把所有東西放在功能開關後面好像可以導致各處的意大利面代碼。如果您使用IoC,並且能夠在vNow/vNext/vPrevious之間進行選擇,那麽就需要維護您的配置。是的更多檢查,是更多的類(componentV1,componentV2,componentV3等),但你實際上有一個更穩定的系統?怎麽樣? vNext是不可靠的?用你的控制塔切換回vNow。過去一周,vNow有一個微妙的錯誤?同樣的事情 - 輕松地返回vPrevious。

沒有麻煩,沒有煩惱,沒有失眠,沒有壓力。

這不是一個夢想。我曾經在那裏工作。希望我能把它賣給我現在的團隊。

一個成功的高速開發環境通常依賴於一個非常嚴格的自動化系統,涉及質量驗證,檢測並拒絕導致回歸的錯誤更改。

功能切換可提供甚至可以提交正在進行的工作,未經測試的更改,而不會因集成分支中的回歸而被拒絕。其中規定了非常好的激勵,以便在功能的生命周期中盡早引入該功能。

偏離真正的CI和在特征分支上移動特征開發的缺點之一是缺乏這種激勵。稍後添加功能切換時,將功能分支合並到集成分支時通常更難,就像任何後期集成一樣。

開發人員(通常是開發經理)通常會尋找與框架相關的兩個結果:易管理性和部署速度。您希望更快,更容易地發送代碼。

提供證據證明該方法有效;嘗試使用特征標記與舊方法構建小型POC。案例研究對策略人員(開發人員\工程師)的影響要小於戰略人員(中層管理人員\產品設計人員)。