有关feature flag toggles的一些问题,例如:


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

问题:


实际上是什么(在DevOps中)“功能标志切换”?
为什么使用它们?


评论

参考信息,而非直接答案-martinfowler.com/articles/feature-toggles.html

我知道人们通常不接受关于“ downvote-explanation”的“询问”。但是,无论谁匿名对这个问题进行投票,都只知道对我来说这样的投票是毫无价值的,因为这些投票很便宜(这样做的投票者不会放弃-1)。答案的匿名下注是不同的...但是这样的下注确实留下了痕迹...

我真的很想知道为什么有人会因为“范围太广”而认为这个问题应该结束,而实际上这是一个很好的问题,应该给出好的答案。

Merci @Evgeny,看来我们在同一页上……但是您是否注意到已撤回1项接近的投票?可能是因为我最近的编辑。

#1 楼

无需重复https://martinfowler.com/articles/feature-toggles.html的内容,因为这是关于什么功能标记切换的令人惊奇的深入解释。我将仅关注DevOps方面。

根据PuppetLabs编写的2014年DevOps状态报告,有四个主要指标可用来衡量IT性能:


更改所需的时间
发布频率
恢复服务的时间
更改失败率

这些也总体上有助于组织绩效。因此,这意味着如果您的IT在这些指标上做得很好,您的底线将得到更大的收益。 :Jez Humble通过构建,测试和部署自动化发布的可靠软件。

在持续交付的情况下,有一个重要的区别将其与持续部署区分开来。这就是何时向用户发布功能的决定。

保持较小的更改,并在功能标记关闭的情况下将半复制的功能部署(复制代码)到生产系统

功能最终完成后,发布是企业的决定。也许新功能的发布需要与某些行销保持一致,或者业务的另一部分发布,例如移动应用程序中的功能。

可以使用A / B实验来发布功能只是部分客户群,或者是特定人群,甚至直接针对一般可用性(GA)。尽管通常只有在足够确定该功能可以正常工作之后,才能发布到GA。可能有人认为这实际上会影响发布频率。

如果没有功能标志切换,这种释放和部署的分离几乎是不可能实现的。

自然,当不需要部署以关闭功能时,恢复服务的时间就大大减少了。

并且通过使用将功能释放给一小部分客户群的功能标志,更改失败率指标也可以得到显着改善。


因此,一种称为功能标志切换的简单机制可以实现更好的IT性能,进而提高整体组织绩效。

在Flickr(有关该主题的最早的公开帖子中)和Etsy上可以找到有关如何在实际公司中完成此操作的绝佳示例。但是许多其他人已经采用了这种做法,并对其进行了详细的讨论,例如Spotify视频中著名的工程文化。

Etsy正在网上发现的多个演示文稿中炫耀其内部工具来管理功能标记Catapult。 Intuit发布了一个名为Wasabi的开源工具,该工具可帮助管理功能标记。

评论


Merci这个有趣/详尽的答案……尽管只有两件事:链接的文章是关于“功能切换”的,而不是“功能标志切换”的(如您在第一段中所写)。您是否同意它们是同义词?如果没有,有什么区别?另外:什么是“ A / B实验”(A =之后和B =之前?可能不是...)。

– Pierre.Vriens♦
17 Mar 5 '17 at 14:44

我同意这些是同义词。我只想尝试弄清楚这个名字,所以没有歧义。我认为“什么是a / b实验”本身就是一个问题……但是简短的答案是,这是两个相互对照的变化形式,例如“ Etsy炫耀”链接中。或在en.wikipedia.org/wiki/A/B_testing中进行了解释

– Evgeny Zislis
17 Mar 5 '17 at 14:48

好的,这就是我一直在等待/希望得到的最后一笔,所以“接受”。

– Pierre.Vriens♦
17 Mar 5 '17 at 14:49

@ Pierre.Vriens“另外:什么是“ A / B实验”(A = After和B = Before?”-您可能会在这个超酷的DevOps SE网站上问这个问题;)

–丹·科尼莱斯库(Dan Cornilescu)
17 Mar 6 '17 at 5:50

#2 楼

肯·穆格(Ken Mugrage)在我的问题下方发表了一条有趣的评论,其中包含指向“功能切换”的说明性链接,其摘要如下:


功能切换是一种强大的技术,允许团队修改系统行为而无需更改代码。它们分为各种用法类别,在实现和管理切换时,必须将这种分类考虑在内。切换会引入复杂性。通过使用智能切换实现做法和适当的工具来管理切换配置,我们可以控制这种复杂性,但我们还应力争限制系统中切换的数量。


上面的摘要仅有助于了解其含义,但是还包含一些示例,说明了使用它们的原因。在进一步消化之后,似乎“功能切换”和“功能标志切换”几乎是彼此的同义词。

但是,解决方案(答案)(问题) ,改变了问题……人们可能会问相关问题,例如:


使用它们的利弊是什么?这是一个强有力的概念,但如果不明智地使用(并适当地固定),它也是一个令人恐惧的概念...
使用它们的例子(好的和坏的)可能是什么?我可以想到其中的很多,其中一些是我很早以前就使用过的(甚至在DevOps还未出现之前就已使用过)。