原创作者：James Frost
原文链接：How We Use Feature Flagging on iOS
原文翻译：Grabin
出色的功能需要花费一些时间来构建。我们每两周发布 WordPress iOS的新版本。但是有时候开发一个功能需要两个多星期。在这种情况下，我们使用Feature Flag 来控制正在开发中的功能，因此我们可以继续构建和测试它们，而无需在还没准备好之前将它们暴露给普通用户。
有了Feature Flag后，你可以根据不同的app的版本向用户呈现不同的用户界面元素或不同的菜单选项——无论是本地调试版本，内部测试版本还是App Store版本。而且这不仅限于用户界面。你甚至还可以使用Feature Flag切换整个后端逻辑的部分。
在本文中，我们将介绍如何在iOS版WordPress中实现Feature Flag。
image.png
实现
构建Configurations
首先，我们要确定用于决定启用或禁用指定功能标志的因素。 在我们的例子中，它基于当前的 build configuration。 Xcode项目中有四个配置：debug, release, internal 和alpha。
image.png
现在，如果能够确定代码中的当前build configuration，我们就可以切换 feature flags。 我们首先添加一个
BuildConfiguration 枚举，每种类型的构建都有一个选项：
enum BuildConfiguration {
/// Development debug build, usually run from Xcode (debug)
case localDeveloper
/// Continuous integration builds,
/// sometimes used to test branches & pull requests (alpha)
case branchTest
/// Internally released betas (internal)
case prereleaseTesting
/// Production build released in the App Store (release)
case appStore
}
接下来，在 BuildConfiguration 枚举中，我们添加一个的计算属性current，该属性返回当前的构建配置：
static var current: BuildConfiguration {
#if DEBUG
return .localDeveloper
#elseif ALPHA_BUILD
return .branchTest
#elseif INTERNAL_BUILD
return .prereleaseTesting
#else
return .appStore
#endif
}
DEBUG，ALPHA_BUILD和INTERNAL_BUILD是Swift flags，在target的 build settings 中定义：
image.png
这就能够让我们在运行时可以通过检查定义了哪些 Swift flags 来区分不同的 build configurations。 在下一步中，我们将能够基于
current 的构建配置启用功能标记。
定义 Feature Flags
我们的 feature flags 本身是在另一个枚举中定义的，该枚举被形象地命名为FeatureFlag：
/// FeatureFlag exposes a series of features to be
/// conditionally enabled on different builds.
@objc
enum FeatureFlag: Int {
case exampleFeature
case revisions
case enhancedSiteCreation
case quickStart
/// Returns a boolean indicating if the feature is enabled
var enabled: Bool {
switch self {
case .exampleFeature:
return true
case .revisions:
return BuildConfiguration.current == .localDeveloper
case .enhancedSiteCreation:
return BuildConfiguration.current ~= [.localDeveloper, .prereleaseTesting]
case .quickStart:
return BuildConfiguration.current != .appStore
}
}
}
enabled的计算属性包含了是否应启用对应FeatureFlag的逻辑。 为了实现这部分逻辑，我们将当前的构建配置与我们要为其启用功能标记的配置进行比较。 在上面的示例中，我们有四个功能标志：
- exampleFeature返回true：始终启用。
- 仅对 localDeveloper 构建配置启用修订。
- 为 localDeveloper 和 prereleaseTesting 构建启用了 enhancedSiteCreation。
- 除appStore外，所有构建均启用了quickStart。
你可能会注意到，上面的 EnhancedSiteCreation 条件使用了一个自定义运算符〜=。 这已经在 BuildConfiguration 中定义为静态函数，它使我们能够将当前的构建配置与一系列配置进行比较：
static func ~=(a: BuildConfiguration, b: Set<BuildConfiguration>) -> Bool {
return b.contains(a)
}
如果我们希望功能可以在多种配置中使用，这将很有用。
最后一步是使用我们的功能标志来启用或禁用功能或UI元素。
使用Feature Flags
我们已经定义了它们，要使用 Feature Flags，我们需要检查它是否已启用。 例如，在这里，当启用了revisions功能标志时，我们才会针对 ** Revisions** 功能执行一个弹窗控制器操作：
if FeatureFlag.revisions.enabled {
alertController.addAction(revisionsAction)
}
根据上述FeatureFlag的实现，只有在进行 local debug builds 调试的时候，才会将revisionsAction添加到我们的 alertController 中。
在iOS版 WordPress 中，当我们开发一个新功能的时候，通常会在应用中添加新的 feature flag。 我们可以把要构建的功能藏在 feature flag后面 ，然后在一切准备就绪的时后，更改 FeatureFlag 的enabled的逻辑，然后发布给测试人员或App Store。
对于某些更大的功能，我们可能先公开进行内部测试，以进行一轮测试，然后在满意地解决所有问题后才将其打开到App Store配置中。 即使在某个功能发布之后，将标志在适当位置保留一两个版本也会很有用，以防需要回滚该功能。
WordPress for iOS应用程序是完全开源的，因此，如果你有兴趣，可以在Github上查看我们对 BuildConfiguration.swift 和 FeatureFlag.swift 的完整实现。
网友评论