部署

多部署测试

入门文档 ,我们演示了如何使用特定部署密钥配置 CodePush 插件。 但是,若要有效地测试发布,使用我们建议在首次创建 Staging CodePush 应用时创建的 和 部署 (或者使用你可能已创建的任何自定义部署) 。 Production 这样,你永远不会向无法验证自己的最终用户发布更新。

备注

客户端回滚功能可帮助在安装导致崩溃的发布后取消阻止用户,以及服务器端回滚 (即) 允许在发现错误版本后防止其他用户安装错误 appcenter codepush rollback 版本。 但是,最好首先防止错误更新广泛发布。

利用 和 部署可以实现如下工作流 Staging Production (自定义!) :

  1. 使用命令命令命令发布对部署的 CodePush 更新 (如果需要更多的 Staging appcenter codepush release-react appcenter codepush release 控制)

  2. 运行应用的过渡/beta 版本,从服务器同步更新,并验证其是否正常工作

  3. 使用 命令将测试版本从 Staging Production 提升 appcenter codepush promote

  4. 运行应用的生产/发布版本,从服务器同步更新并验证其是否正常工作

    提示

    如果要采取更谨慎的方法,甚至可以选择在 #3 中执行"分步推出",这样,就可以通过更新 (来缓解其他潜在风险 (就像在 #2 中测试是否接触所有可能的设备/条件一样) 只需将生产更新提供给一定比例的用户 (例如 appcenter codepush promote -a <ownerName>/<appName> -s Staging -d Production -r 20) 。 然后,在等待合理的时间来查看是否有崩溃报告或客户反馈后,可以通过运行将其扩展到整个观众 appcenter codepush patch -a <ownerName>/<appName> Production -r 100

以上步骤引用应用的 "过渡生成" 和 "生产内部版本"。 如果你的生成过程已为每个 "环境" 生成不同的二进制文件,则无需进一步阅读,因为交换 CodePush 部署密钥类似于处理应用程序使用的任何其他服务的特定于环境的配置 (例如 Facebook) 。 但是,如果你正在查找有关如何设置生成过程以适应此操作的示例,请参阅以下部分,具体取决于你的应用面向的平台。

Android

Android Gradle 插件允许为每个 "生成类型" ((如调试、发布) )定义自定义配置设置。 利用此机制,你可以轻松地将调试版本配置为使用 CodePush 过渡部署密钥,并使用你的发布版本来使用 CodePush 生产部署密钥。

备注

作为提醒,你可以通过在终端中运行来检索这些密钥 appcenter codepush deployment list -a <ownerName>/<appName> -k

若要进行此设置,请执行以下步骤:

对于响应本机 >= 0.60

  1. 打开项目的应用程序级 build.gradle 文件 (例如, android/app/build.gradle 在标准响应本机项目中)

  2. 找到 android { buildTypes {} } 部分,并定义 resValue debug 和生成类型的条目 releaseStaging 分别引用和 Production 部署密钥。

    android {
        ...
        buildTypes {
            debug {
                ...
                // Note: CodePush updates shouldn't be tested in Debug mode as they're overriden by the RN packager. However, because CodePush checks for updates in all modes, we must supply a key.
                resValue "string", "CodePushDeploymentKey", '""'
                ...
            }
            releaseStaging {
                ...
                resValue "string", "CodePushDeploymentKey", '"<INSERT_STAGING_KEY>"'
                // Note: It's a good idea to provide matchingFallbacks for the new buildType you create to prevent build issues
                // Add the following line if not already there
                matchingFallbacks = ['release']
                ...
            }
            release {
                ...
                resValue "string", "CodePushDeploymentKey", '"<INSERT_PRODUCTION_KEY>"'
                ...
            }
        }
        ...
    }
    

备注

strings.xml如果要在生成过程中配置部署密钥,请记住从中删除密钥 *

备注

releaseStaging由于此行,的命名约定非常重要。

对于响应 Native v 0.29-v 0.59

  1. 打开 MainApplication.java 文件并进行以下更改:

    @Override
    protected List<ReactPackage> getPackages() {
         return Arrays.<ReactPackage>asList(
             ...
             new CodePush(BuildConfig.CODEPUSH_KEY, MainApplication.this, BuildConfig.DEBUG), // Add/change this line.
             ...
         );
    }
    
  2. 打开应用的 build.gradle 文件 (例如, android/app/build.gradle 在标准响应本机项目中)

  3. 找到 android { buildTypes {} } 部分,并定义 buildConfigField debug 和生成类型的条目 releaseStaging 分别引用和 Production 部署密钥。 如果需要,可以在文件中定义键文本, gradle.properties 然后在此处引用它们。 无论哪种方式都行,这是个人偏好的问题。

    android {
        ...
        buildTypes {
            debug {
                ...
                // Note: CodePush updates shouldn't be tested in Debug mode as they're overridden by the RN packager. However, because CodePush checks for updates in all modes, we must supply a key.
                buildConfigField "String", "CODEPUSH_KEY", '""'
                ...
            }
    
            releaseStaging {
                ...
                buildConfigField "String", "CODEPUSH_KEY", '"<INSERT_STAGING_KEY>"'
    
                // Note: It's a good idea to provide matchingFallbacks for the new buildType you create to prevent build issues
                // Add the following line if not already there
                matchingFallbacks = ['release']
                ...
            }
    
            release {
                ...
                buildConfigField "String", "CODEPUSH_KEY", '"<INSERT_PRODUCTION_KEY>"'
                ...
            }
        }
        ...
    }
    

    提示

    提醒一下,可以通过从终端运行 来 appcenter codepush deployment list -a <ownerName>/<appName> --displayKeys 检索这些密钥。

    备注

    的命名约定 releaseStaging 十分重要,因为 此行为 。

  4. 通过定义的生成配置(而不是字符串文本)将部署密钥 CodePush 传递给构造函数。

对于 React Native v0.19 - v0.28

打开 MainActivity.java 文件,并做出以下更改:

@Override
protected List<ReactPackage> getPackages() {
    return Arrays.<ReactPackage>asList(
        ...
        new CodePush(BuildConfig.CODEPUSH_KEY, this, BuildConfig.DEBUG), // Add/change this line.
        ...
    );
}

备注

如果在 Gradle 文件中为生成设置提供了不同的名称,请确保在 Java 代码中反映该名称。

大功告成! 现在,运行或生成应用时,调试版本将自动配置为与部署同步,并且发布版本将配置为 Staging 与部署 Production 同步。

备注

默认情况下,该命令生成并部署应用的调试版本,因此,如果要测试发布/生产版本,请 react-native run-android 运行"react-native run-android --variant release"。 请参阅 React Native文档 ,详细了解如何为 Android 应用配置和创建发布版本。

如果要在同一设备上同时安装调试版本和发布版本 (强烈建议!) ,则需要确保调试版本具有发布版本中的唯一标识和图标。 否则,OS 或你无法区分这两者。 可以通过执行以下步骤来配置唯一标识:

  1. build.gradle 文件中,为调试生成类型指定 字段,为调试生成提供 OS 版本的唯一标识 applicationIdSuffix (com.foo 例如 vs. com.foo.debug) 。

    buildTypes {
        debug {
            applicationIdSuffix ".debug"
        }
    }
    
  2. 在应用中创建目录结构,该结构允许重写资源 (如字符串、图标、布局) app/src/debug/res 调试版本

  3. 在 #2 中创建的调试 res 目录下创建一个目录,然后从该目录 values strings.xml 复制 app/src/main/res/values 现有文件

  4. 打开新的调试 strings.xml 文件,将 <string name="app_name"> 元素的值更改为其他 (如 foo-debug) 。 这确保了调试生成现在具有一个不同的显示名称,以便你可以将其与发布版本区分开来。

  5. 还可以在 app/src/debug/res 目录中为你希望为调试版本更改的所有应用程序图标创建 "镜像" 目录。 此部分在技术上并不重要,但如果其图标明显不同,它可以更轻松地在设备上快速发现调试版本。

大功告成! 有关 Android 中资源合并工作方式的详细信息,请参阅 资源合并

iOS

Xcode 允许你为每个 "配置" ((如调试、发布) )定义自定义生成设置,可以将其作为 info.plist 文件中的键值引用 (如 CodePushDeploymentKey 设置) 。 此机制允许你轻松地将生成配置为生成二进制文件,这些二进制文件配置为与不同的 CodePush 部署同步。

若要进行此设置,请执行以下步骤:

  1. 打开 Xcode 项目并在 " 项目导航器 " 窗口中选择项目

  2. 请确保选择项目节点,而不是一个目标

  3. 选择 " 信息 " 选项卡

  4. 单击 " + 配置 " 部分中的按钮,然后选择 "发布" 配置

    Configuration

  5. 将新的配置 过渡 命名 (或任何喜欢的内容)

  6. 选择 " 生成设置 " 选项卡

  7. 单击 + 工具栏上的按钮,然后选择 "添加 User-Defined 设置"

    设置

    将此设置 MULTI_DEPLOYMENT_CONFIG 名称。 中转到 "设置" 并添加 $(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME) " 发布" 值。 在此之后 $(BUILD_DIR)/Release$(EFFECTIVE_PLATFORM_NAME)暂存 添加值。

    MultiDeploymentConfig

    备注

    对于 Xcode 10 和更低版本:转到 " 生成位置" > 按配置生成产品路径 > 过渡 并将 暂存 值从更改 $(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)$(BUILD_DIR)/Release$(EFFECTIVE_PLATFORM_NAME)

    BuildFilesPath

    备注

    由于 https://github.com/facebook/react-native/issues/11813 ,我们必须执行此步骤,使其能够使用除 RN 0.40.0 或更高版本上的调试或发布外的其他配置。

  8. 再次单击 + 工具栏上的按钮,然后选择" 添加User-Defined设置"

    将此设置命名,展开它,为"过渡"配置指定过渡部署密钥,为"发布"配置 CODEPUSH_KEY 指定"生产"部署密钥。

    设置密钥

    备注

    提醒一下,可以通过从终端运行 来 appcenter codepush deployment list -a <ownerName>/<appName> --displayKeys 检索这些密钥。

  9. 打开项目的 Info.plist 文件,将条目 CodePushDeploymentKey 的值更改为 $(CODEPUSH_KEY)

    Info.plist

大功告成! 现在,运行或生成应用时,过渡版本将自动配置为与过渡部署同步,并且发布版本将配置为与 生产部署同步

备注

如果发现错误消息 , ld: library not found for ... 请检查此问题 ,了解可能的解决方案。

此外,如果要为它们提供单独的名称或图标,可以修改 、 和 生成设置,这样,当在同一设备上安装时,过渡版本与发布版本 Product Bundle Identifier Product Name Asset Catalog App Icon Set Name 可以区分。

动态部署分配

上一部分说明了如何在向最终用户广泛发布更新之前使用多个 CodePush 部署来有效地测试更新。 但是,由于该工作流以静态方式将部署分配嵌入到实际二进制文件中,因此暂存或生产生成只会同步来自该部署的更新。 在许多情况下,这就足够了,因为仅希望团队、客户、利益干系人等与预生产版本同步,因此,他们只需要知道如何与过渡版本同步的生成。 但是,如果要执行 A/B 测试,或向特定用户提供应用的早期访问,将特定用户或受众动态放置到 (或) 特定部署中可能会很有用。

若要实现此工作流,请在调用方法时指定要使当前用户与之同步的部署密钥 codePush 。 指定后,此密钥将覆盖应用的 info.plist 中提供的 "默认值", (iOS) 或 MainActivity (Android) 文件。 这样,便可以生成过渡或生产生成,这也能够根据需要动态 "重定向"。

// Imagine that "userProfile" is a prop that this component received
// that includes the deployment key that the current user should use.
codePush.sync({ deploymentKey: userProfile.CODEPUSH_KEY });

进行这种更改后,现在就是选择应用如何为当前用户确定正确的部署密钥。 在实践中,通常有两种解决方法:

  1. 公开用于随时更改部署的用户可见机制。 例如,设置页面可能具有用于启用 "beta" 访问的切换。 如果你不关心预生产更新的隐私,并且你的超级用户可能想要选择使用之前的 (并且可能有错误) 自行更新 (如 Chrome 通道) ,则此模型非常适合。 但是,此解决方案将决策置于用户的手中,这并不能帮助你以透明方式运行 A/B 测试。

  2. 使用一段额外的元数据(指示应与之同步的部署)来批注用户的服务器端配置文件。 默认情况下,你的应用可以使用二进制嵌入的密钥,但在用户经过身份验证后,你的服务器可以选择将它们 "重定向" 到不同的部署,这允许你根据需要增量将特定用户或组放入不同的部署中。 甚至可以选择在本地存储中存储服务器响应,使其成为新的默认值。 如何将密钥与用户的配置文件一起存储完全取决于你的身份验证解决方案 (例如,Auth0、Firebase、custom DB + REST API) ,但通常非常简单。

    备注

    如果需要,还可以实现允许最终用户在不同的部署之间切换的混合解决方案,同时还允许服务器重写该决策。 这样一来,你拥有一个"部署解析"层次结构,可确保应用能够开箱更新自身,最终用户可以通过提前访问位来感到轻松,但还可以根据需要对用户运行 A/B 测试。

由于我们建议使用部署对更新 (进行预发布测试,如上一部分) 所述,使用它进行用户 A/B 测试并不一定有意义,而不是允许提前访问 (,如上述选项 #1) 所述。 Staging 因此,我们建议充分利用自定义应用部署,以便可以细分用户,但这样做适合你的需求。 例如,可以创建长期甚至一次部署,向其中发布应用的变体,然后将某些用户放入其中,以查看他们如何参与。

// #1) Create your new deployment to hold releases of a specific app variant
appcenter codepush deployment add -a <ownerName>/<appName> test-variant-one

// #2) Target any new releases at that custom deployment
appcenter codepush release-react -a <ownerName>/<appName> -d test-variant-one

备注

部署"安装指标"中报告的总用户计数将考虑从一个部署"切换"到另一个部署的用户。 例如,如果生产部署当前报告的用户总数为 1,但将该用户动态切换为"过渡",则生产部署将报告 0 个用户总数,而过渡部署将报告 1 (切换用户) 。 即使使用基于运行时的部署重定向解决方案,此行为也允许准确跟踪发布采用情况。