是什么说服（并强制）开发人员开始使用功能标记切换的好方法？
更多有关功能标志切换的信息，请参见问题Q：如何使用功能标志切换，问题Q：什么是功能标志切换，在Pete Hodgson在Martin Fowler博客上有关该主题的文章中进行了广泛介绍。
#1 楼
功能切换是高速开发中的常见做法，因为它们使开发与发布脱钩。开发团队可以在禁用状态下将新功能“软发布”到生产中。这样可以随时释放该功能。如果该功能依赖于其他工作或准备工作，则无需等待主要版本发布即可。就“说服”开发人员使用它们而言，这是一个练习。为其提供的自由辩护。我的经验是，对开发人员而言，这并不是一个艰难的选择。管理层往往不愿尝试新事物。尝试以下操作：
查找功能切换框架。管理/业务可能更容易
尝试由通用系统支持的事情
从小做起。在试用版的基础上引入切换系统，以演示其功能。
演示切换系统进行A / B测试的能力。为您的Web场的一部分启用切换，然后收集行为指标。事实证明，页面布局的微小差异会对零售应用程序（例如Ebay，Amazon）的收入产生巨大影响
评论
+1为框架位。我见过太多的人滚动他们自己的功能开关，它总是令人讨厌，讨厌的代码。
–Jduv
17年3月6日在1:48
关于框架位，Intuit有一个有趣的OSS，名为Wasabi github.com/intuit/wasabi
– Evgeny Zislis
17 Mar 6 '17 at 3:28
关于说服其他开发人员的书籍推荐-Terrence Ryan的《推动技术变革》
–死亡
17 Mar 8 '17 at 7:38
#2 楼
在理想的世界中，我认为您会推出一个新版本并感到惊讶！没有什么改变。这是因为您所有的新功能都位于开关后面，而这些开关会在关闭状态下熄灭。部署后，您确认推出的服务仍然有效，电话再也不会响铃（除非要让电话响就是这个意思，等等。一旦返回已知的稳定操作，您就开始启用并验证新部署的功能。
现在您的答案：您想如何在一个几乎不费吹灰之力的团队中工作，而我们的用户之所以喜欢我们，是因为我们的站点和服务坚如磐石？
我就是这个团队。
如果需要，可以在这里停止阅读。
将所有内容置于功能开关的后面似乎会导致意大利面条式代码遍地开花。如果您使用IoC，并且能够在vNow / vNext / vPrevious之间进行选择，那么这将取决于维护您的配置。是的，还有更多的签入程序，还有的是更多的类（componentV1，componentV2，componentV3等），但是实际上您有一个更稳定的系统吗？怎么样？ vNext没意思吗？使用您的控制塔切换回vNow。一周了，vNow有一个小错误？同样的事情-轻松回到vPrevious。
不用麻烦，不用担心，不要失去睡眠，没有压力。
这不是白日梦。我曾经在那里工作。希望我可以把它卖给我目前的团队。
#3 楼
成功的高速开发环境通常依赖于相当严格的自动化系统，该系统涉及质量验证以及对导致退步的错误更改的检测和拒绝。功能开关提供了提交甚至进行中的功能，未经测试的更改，而不会因为在集成分支中引起回归而被拒绝。这就构成了一个很好的动机来引入功能，从而在功能的生命周期的早期就进行了切换。 。稍后，将功能分支合并到集成分支中时，添加功能切换通常会比较困难，就像任何后期集成一样。
#4 楼
开发人员（通常是开发经理）通常会寻找与框架相关的两个结果：易于管理和部署速度。您希望更快，更轻松地发布代码。提供证明该方法有效的证据。尝试使用功能标记而非旧方法来构建小型POC。案例研究对战术人员（开发人员/工程师）的重要性不如战略人员（中层管理人员/产品设计师）重要。
#5 楼
开发人员无法决定具有功能切换的理由。这是产品所有者要关心的事情。开发人员以最可持续和安全的方式实现此更改。我对这个问题提出了批评。评论
我去过以开发人员为产品所有者的组织。我已经看到产品管理几次像产品所有者一样。我去过的地方似乎没人拥有任何东西。因此，您的陈述大约符合我的经验的三分之一。鼓励开发人员以在生产中可以更好地工作的方式编写东西，对我来说通常是一件好事。您能引用任何权威来支持您的观点吗？
–小鸡
19年4月13日在13:58
评论
devops.stackexchange.com/questions/4/…问题的窄版。糟糕，我现在才看到您新的评论（和更新）。在我刚刚发布有关它们的新问题之后。也许您想发布我的新问题的答案（您有更多的空间来实际解释这些问题）？如果这样做，请确保它不是仅链接的答案（我相信您知道这对SE网站意味着什么，对吧？）。