(翻译) 我们如何在iOS上使用Feature Flagging

原创作者：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 的完整实现。