软件交付功能检查表_连续交付–第3部分–功能切换

软件交付功能检查表

上一章 ： 持续交付之路–第2部分–可见性

连续交付中的关键要素之一是您停止使用VCS存储库中的功能分支。 每个人都在MASTER分支上工作。 在过渡到持续部署的过程中，我们从SVN切换到Git ，它可以更好地处理代码合并，并且比SVN具有其他优势。 但是SVN和基本上所有其他VCS都可以正常工作。

对于刚刚了解这种方法的人来说，这听起来有些疯狂，因为他们认为开发人员在代码完成并通过所有测试之前无法签入代码。 但这绝对不是事实。 持续部署中的工作

我们告诉开发人员至少每天至少一次检入他们的代码。 那怎么办呢？ 开发人员无法在一天内完成任务吗？ 那么，很少有策略可以支持这种发展模式。

功能切换

告诉开发人员他们每天至少必须签入一次代码，这将使您产生以下React：“但是我的代码尚未完成，我无法签入”。 克服此“问题”的方法是使用功能切换。

Feature Toggle是软件开发中的一种技术，它试图提供一种替代方法来维护多个源代码分支，称为功能分支。 连续发布和连续部署使您能够快速获得有关代码的反馈。 这要求您尽早集成更改。 功能分支为该过程引入了旁路。 功能切换将您带回轨道，但是如果切换为“关闭”，则功能的执行路径仍然是“死”和“未测试”。 但是，仅通过将切换设置为“ on”，即可启用新的执行路径的工作量很小。

那么真正的功能切换是什么？

功能切换基本上是代码中的“ if”语句，它是标准代码流的一部分。 如果切换开关为“ on”（“ if”语句== true），则执行代码；如果切换开关为off，则不执行代码。
您添加到系统中的每个新功能都必须包含在功能切换中。 这样，开发人员可以检入未完成的代码，只要它们可以编译即可，除非将切换开关设置为“ on”，否则它永远不会执行。 如果您正确地设计代码，将会看到在大多数情况下，对于特定功能，在代码中只有一个位置切换“ if”语句。

功能切换不必为布尔值。 您可以使用枚举，字符串，整数或任何其他值的功能切换，只要它适合您的流程即可。 例如，假设您要从一个数据库迁移到另一个数据库。 在迁移过程中，功能切换可以具有4个值：

1. 从旧数据库中读取；
2. 从旧数据库读取并回退到新数据库；
3. 从新数据库读取并回退到旧数据库；
4. 仅使用新数据库。

使用功能切换可快速获得反馈

功能切换还有另一个很大的优势。 它们不仅用于检入未完成的代码，还用于获取快速反馈。

一旦开发人员认为某项功能已经完成，甚至完成了一半，您就可以使用功能切换按钮来公开新功能，以进行内部测试或从产品经理那里获得快速反馈。 例如，您可以在“ if”语句中使用该语句检查登录用户是否具有某些特权；例如， 或在您的公司工作，甚至等于一个特定的用户ID，那么新功能就可以打开并投入使用。 这样，产品经理就可以在实时系统上实时体验生产中的新功能（即使尚未完成），并向开发人员提供有关产品的快速反馈。 在产品经理看到并体验新功能的同时，其他用户也不受此影响，因为对于他们来说，功能切换处于“关闭”状态。

内部测试

当开发人员宣布完成一项新功能时，Wix首先在内部向公司中的所有员工开放新功能以进行内部测试。 这样，我们使用自己的员工进行质量检查，这使我们有数百个质量检查用户，它们只是系统的常规用户。 在几天的几个小时内对内部新功能进行测试之后，我们向公众开放（使用或不使用A / B测试 ，具体取决于用例）。

使用功能切换进行重构

功能切换的另一个非常有用的用例是重构。 由于所有开发人员都在MASTER分支上工作，因此重构可能是一个挑战。 但是使用功能切换可以减轻痛苦。

通常，在重构时，您更改一个或多个方法实现，替换类，甚至更改整个工作流程。 现在，当使用连续交付并且您的代码必须每天至少签入一次时，这会影响重构的方式。

在进行大型重构工作时，请勿更改任何现有代码。 您要做的是编写一个新的（和改进的）代码来代替旧的代码。 使用功能切换可以控制何时使用新的和重构的代码以及旧的和“不太好”的代码。 完成重构工作并打开功能切换以使用新代码后，就可以安全地从系统中删除旧代码。

使用此方法有一个非常重要的好处，只要您不删除旧代码，就可以在生产中发现新代码中的错误时始终返回到旧代码（翻转切换）。

功能切换管理器和BI

使用功能切换时，重要的是要知道哪些功能切换处于活动状态，查看它们的值是什么，它们处于激活状态的时间，并能够实时修改切换。

为了完成这项工作，我们在Wix建立了一个名为Feature Toggle Manager的库（即将以开源形式打开）。 功能切换管理器具有功能切换及其值的列表。 它由数据库支持，我们可以在其中通过后台修改值。

我们使用功能切换管理器在代码中提供“ if”语句，功能的值是多少。 Feature Toggle Manager具有一组策略，用于确定切换值。 我们使用的一些策略是：用户凭证，Wix员工，GEO位置，浏览器用户代理和百分比。 您可以构建自己的策略来确定Feature Toggle Manager在给定用例时将返回哪个值。 具有功能的默认值很重要，该默认值定义了系统的默认行为。 功能成熟后，默认值也可以随时间变化。

由于每个流都使用功能切换管理器来获取切换值，因此我们还可以针对当前事件在当前用户流中处于活动状态并已传递的每个事件（及其值）报告给我们的BI系统。

清洁功能切换

功能切换不应永远存在于代码中。 在打开功能并确定不需要将切换切换回非活动状态之后，开发人员应返回代码并从代码中删除“ if”语句，将其从不必要的if语句和未使用的切换中清除。 功能切换管理器可以为您提供帮助，因为它向您显示了所有功能以及它们的激活时间。 您也可以在代码中进行快速搜索，以找到使用了位置功能切换的地方。

使用功能切换进行测试

测试功能可能是一个挑战。 请记住，执行持续交付意味着您必须使用测试驱动开发进行工作。 通常，使用单元测试不会有任何问题，因为您可以测试实际方法，并且在大多数情况下会绕过功能切换流管理。 但是，当您编写集成测试时，您可能会遇到问题，因为您正在测试端到端流程，并且必须通过Feature Toggle“ if”语句（如果该语句同时处于“关闭”状态，以测试回归和“打开”状态）测试新功能流程。

这是Feature Toggle Manager可以帮助您的另一种情况。 在安装过程中进行的测试中，可以将Feature Toggle Manager中的值设置为要测试的任何流程。 由于“功能切换”始终具有默认值（通常为关闭状态），因此所有旧测试均应像以前一样工作，因为您无需更改旧行为。 但是，当您为新功能编写集成测试时，需要在测试设置过程中将功能切换设置为“ on”，从而使流程能够通过新功能并进行测试。

下一章： A / B测试

参考： 持续交付–第3部分–来自ACG的 合作伙伴 Aviran Mordo在Aviran's Place博客上的功能切换 。

翻译自: https://www.javacodegeeks.com/2013/05/continuous-delivery-part-3-feature-toggles.html

软件交付功能检查表