如何说服开发人员开始使用功能开关

57次阅读
没有评论

问题描述

想知道如何说服(并强制)开发人员开始使用功能开关。他们了解到功能开关是一种好的实践,并且应该被实现到开发人员编写的代码中。例如,Etsy公司将其视为文化的重要组成部分。用户希望了解如何说服开发人员开始使用功能开关,并希望有一些方法来强制他们使用。

解决方案

请注意以下操作注意版本差异及修改前做好备份。

方案1

功能开关在高速开发中是一种常见的实践,因为它们将开发与发布解耦。开发团队可以将新功能以禁用状态“软发布”到生产环境中。这样,该功能可以随时发布。如果该功能依赖于其他工作或准备工作,它不必等待主要发布才能进入生产环境。
至于“说服”开发人员使用它们,这是一个为其自由性辩护的过程。根据我的经验,对开发人员来说,这并不是一个难以说服的事情。相反,管理层往往不愿尝试新事物。可以尝试以下方法:
1. 找到一个功能开关框架。管理层/业务可能更愿意尝试一些由常见系统支持的东西。
2. 从小处开始。试用性地引入开关系统,用一个能够展示其效用的功能进行试验。
3. 展示开关进行A/B测试的能力。为Web服务器群的子集启用开关,然后收集行为数据。对于零售应用程序(如Ebay、亚马逊),页面布局的微小差异已被证明对收入产生巨大影响。

方案2

在理想情况下,你可以发布一个新版本,但是什么都不会改变。这是因为所有新功能都在关闭的开关后面。
发布后,你可以验证已部署的服务是否仍然正常工作,电话不再响个不停(除非你的目的就是让电话响个不停)。一旦回到已知的稳定操作状态,你可以开始启用和验证新部署的功能。
现在,回答你的问题:你想在一个团队中工作,值班几乎是一件轻而易举的事情,我们的用户喜欢我们,因为我们的网站和服务非常稳定吗?
这就是我想要加入的团队。
如果你使用IoC并能够在vNow/vNext/vPrevious之间进行选择,那么问题就变成了如何维护你的配置。是的,需要更多的提交,需要更多的类(componentV1、componentV2、componentV3等),但你实际上拥有了一个更稳定的系统。为什么呢?vNext有问题?使用控制台切换回vNow。过了一周,vNow出现了一个微妙的错误?同样的操作 – 轻松切换回vPrevious。
没有麻烦,没有担忧,没有失眠,没有压力。
这不是一个空想。我曾经在那里工作过。但愿我能向我的现任团队推销这个想法。

方案3

成功的高速开发环境通常依赖于一个严格的自动化系统,其中包括质量验证、检测和拒绝导致回归的错误更改。
功能开关提供了即使是工作中的、未经测试的更改也可以提交的能力,而不会因为在集成分支中引发回归而被拒绝。这构成了在功能的生命周期早期引入功能开关的非常好的激励。
从真正的持续集成偏离并将功能开发移至功能分支的一个缺点是缺乏这样的激励。在将功能分支合并到集成分支时,稍后再添加功能开关通常更加困难,就像任何后期集成一样。

方案4

开发人员(通常也包括开发经理)通常寻求与框架相关的两个结果:管理的便捷性和部署的速度。你希望更快、更容易地发布代码。
提供证据证明这种方法是有效的;尝试使用功能开关与以前的方式构建一个小的POC。对于战术人员(开发人员/工程师)来说,案例研究的重要性不如对战略人员(中层管理/产品设计师)来说。

方案5

是否使用功能开关不是开发人员决定的,而是产品负责人关心的事情。开发人员以最可持续和安全的方式启用此更改。我对这个问题持批评态度。
评论:我曾经在开发人员就是产品负责人的组织中工作过。我曾几次看到产品管理像产品负责人一样行事。我也曾在没有人似乎拥有任何东西的地方工作过。所以你的说法大致符合我三分之一的经验。鼓励开发人员以更适合生产环境的方式编写代码似乎是一件好事。你能引用一些权威来支持你的观点吗?

正文完