You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on May 20, 2025. It is now read-only.
@@ -440,6 +440,101 @@ For more details about how the `release-react` command works, as well as the var
440
440
441
441
If you run into any issues, or have any questions/comments/feedback, you can ping us within the [#code-push](https://discord.gg/0ZcbPKXt5bWxFdFu) channel on Reactiflux, [e-mail us](mailto:[email protected]) and/or check out the [troubleshooting](#debugging--troubleshooting) details below.
442
442
443
+
444
+
## Multi-Deployment Releases
445
+
446
+
In our [getting started](#getting-started) docs, we illustrated how to configure the CodePush plugin, using a specific deployment key. However, in order to effectively test your releases, it is critical that you leverage the `Staging` and `Production` deployments that are auto-generated when you first created your CodePush app. This way, you never release an update to your end users that you haven't been able to validate yourself.
447
+
448
+
*NOTE: Our client-side rollback feature can help mitigate releases which result in an app crash, and server-side rollbacks (e.g. `code-push rollback`) allow you to prevent additional users from installing a bad release, however, it's obviously better if you can prevent an erroneous update from being broadly released in the first place.*
449
+
450
+
Setting this up requires unique steps for each platform, so refer to the following sections for an example of how this can be achieved in your React Native app, depending on the platform(s) you are targeting.
451
+
452
+
### Android
453
+
454
+
The [Android Gradle plugin](http://google.github.io/android-gradle-dsl/current/index.html) allows you to define custom config settings for each "build type" (e.g. debug, release), which in turn are generated as properties on the `BuildConfig` class that you can reference from your Java code. This mechanism allows you to easily configure your debug builds to use your CodePush staging deployment key, and your release builds to use your CodePush production deployment key.
455
+
456
+
To set this up, perform the following steps:
457
+
458
+
1. Open your app's `build.gradle` file (e.g. `android/app/build.gradle`)
459
+
460
+
2. Find the `android { buildTypes }` section and define `buildConfigField` entries for both your `debug` and `release` build types, which reference your `Staging` and `Production` deployment keys respectively.
*NOTE: As a reminder, you can retrieve these keys by running `code-push deployment ls <APP_NAME> -k` from your terminal.*
483
+
484
+
4. Open up your `MainAtivity.java` file and change the `CodePush` constructor to pass the deployment key in via the build config you just defined, as opposed to a string literal.
485
+
486
+
```java
487
+
new CodePush(BuildConfig.CODEPUSH_KEY, this, BuildConfig.DEBUG);
488
+
```
489
+
490
+
*Note: If you gave your build setting a different name in your Gradle file, simply make sure to reflect that in your Java code.*
491
+
492
+
And that's it! Now when you run or build your app, your debug builds will automatically be configured to sync with your `Staging` deployment, and your release builds will be configured to sync with your `Production` deployment.
493
+
494
+
If you want to be able to install both debug and release builds simultaneously on the same device, then you can also specify an [`applicationIdSuffix`](http://google.github.io/android-gradle-dsl/current/com.android.build.gradle.internal.dsl.BuildType.html#com.android.build.gradle.internal.dsl.BuildType:applicationIdSuffix) field for your debug build type, so that the OS sees them as seperate apps (e.g. `com.foo` and `com.foo.debug`).
495
+
496
+
```groovy
497
+
buildTypes {
498
+
debug {
499
+
applicationIdSuffix ".debug"
500
+
}
501
+
}
502
+
```
503
+
504
+
Additionally, if you want to give them seperate names and/or icons, you can define newresourcefiles (`strings.xml` and drawables) for your debug build by creating a `app/src/debug`directory. View [here](http://tools.android.com/tech-docs/new-build-system/resource-merging) for more details on how resource merging works in Android.
505
+
506
+
Finally, refer to the [React Native docs](http://facebook.github.io/react-native/docs/signed-apk-android.html#content) for details about how to configure and create release builds for your Android apps.
507
+
508
+
### iOS
509
+
510
+
Xcode allows you to define custom build settings for each "configuration" (e.g. debug, release), which can then be referenced as the value of keys within the `Info.plist`file. This mechanism allows you to easily configure your debug builds to use your CodePush staging deployment key, and your release builds to use your CodePush production deployment key.
511
+
512
+
To set this up, perform the following steps:
513
+
514
+
1. Open up your Xcode project and select your project in the `Project navigator`window
515
+
516
+
2. Select the `Build Settings` tab
517
+
518
+
3. Click the `+` button on the toolbar and select `Add User-Defined Setting`
4. Name thisnewsetting something like `CODEPUSH_KEY`, expand it, and specify your `Staging` deployment key for the `Debug` config and your `Production` deployment key for the `Production` config.
And that's it! Now when you run or build your app, your debug builds will automatically be configured to sync with your `Staging` deployment, and your release builds will be configured to sync with your `Production` deployment.
533
+
534
+
Additionally, if you want to give them seperate names and/or icons, you can modify the `Product Name` and `Asset Catalog App Icon Set Name` build settings, so that the debug configuration has a unique value.
@@ -985,100 +1080,6 @@ Now you'll be able to see CodePush logs in either debug or release mode, on both
985
1080
| Images dissappear after installing CodePush update | If your app is using the React Native assets system to load images (i.e. the `require(./foo.png)` syntax), then you **MUST** release your assets along with your JS bundle to CodePush. Follow [these instructions](#releasing-updates-javascript--images) to see how to do this. |
986
1081
| No JS bundle is being found when running your app against the iOS simulator | By default, React Native doesn't generate your JS bundle when running against the simulator. Therefore, if you're using `[CodePush bundleURL]`, and targetting the iOS simulator, you may be getting a `nil` result. This issue will be fixed in RN 0.22.0, but only for release builds. You can unblock this scenario right now by making [this change](https://github.com/facebook/react-native/commit/9ae3714f4bebdd2bcab4d7fdbf23acebdc5ed2ba) locally.
987
1082
988
-
## Multi-Deployment Releases
989
-
990
-
In our [getting started](#getting-started) docs, we illustrated how to configure the CodePush plugin, using a specific deployment key. However, in order to effectively test your releases, it is critical that you leverage the `Staging` and `Production` deployments that are auto-generated when you first created your CodePush app. This way, you never release an update to your end users that you haven't been able to validate yourself.
991
-
992
-
*NOTE: Our client-side rollback feature can help mitigate releases which result in an app crash, and server-side rollbacks (e.g. `code-push rollback`) allow you to prevent additional users from installing a bad release, however, it's obviously better if you can prevent an erroneous update from being broadly released in the first place.*
993
-
994
-
Setting this up requires unique steps for each platform, so refer to the following sections for an example of how this can be achieved in your React Native app, depending on the platform(s) you are targeting.
995
-
996
-
### Android
997
-
998
-
The [Android Gradle plugin](http://google.github.io/android-gradle-dsl/current/index.html) allows you to define custom config settings for each "build type" (e.g. debug, release), which in turn are generated as properties on the `BuildConfig` class that you can reference from your Java code. This mechanism allows you to easily configure your debug builds to use your CodePush staging deployment key, and your release builds to use your CodePush production deployment key.
999
-
1000
-
To set this up, perform the following steps:
1001
-
1002
-
1. Open your app's `build.gradle` file (e.g. `android/app/build.gradle`)
1003
-
1004
-
2. Find the `android { buildTypes }` section and define `buildConfigField` entries for both your `debug` and `release` build types, which reference your `Staging` and `Production` deployment keys respectively.
*NOTE: As a reminder, you can retrieve these keys by running `code-push deployment ls <APP_NAME>-k` from your terminal.*
1027
-
1028
-
4. Open up your `MainAtivity.java` file and change the `CodePush` constructor to pass the deployment key in via the build config you just defined, as opposed to a string literal.
*Note: If you gave your build setting a different name in your Gradle file, simply make sure to reflect that in your Java code.*
1035
-
1036
-
And that's it! Now when you run or build your app, your debug builds will automatically be configured to sync with your `Staging` deployment, and your release builds will be configured to sync with your `Production` deployment.
1037
-
1038
-
If you want to be able to install both debug and release builds simultaneously on the same device, then you can also specify an [`applicationIdSuffix`](http://google.github.io/android-gradle-dsl/current/com.android.build.gradle.internal.dsl.BuildType.html#com.android.build.gradle.internal.dsl.BuildType:applicationIdSuffix) field for your debug build type, so that the OS sees them as seperate apps (e.g. `com.foo` and `com.foo.debug`).
1039
-
1040
-
```groovy
1041
-
buildTypes {
1042
-
debug {
1043
-
applicationIdSuffix ".debug"
1044
-
}
1045
-
}
1046
-
```
1047
-
1048
-
Additionally, if you want to give them seperate names and/or icons, you can define new resource files (`strings.xml` and drawables) for your debug build by creating a `app/src/debug` directory. View [here](http://tools.android.com/tech-docs/new-build-system/resource-merging) for more details on how resource merging works in Android.
1049
-
1050
-
Finally, refer to the [React Native docs](http://facebook.github.io/react-native/docs/signed-apk-android.html#content) for details about how to configure and create release builds for your Android apps.
1051
-
1052
-
### iOS
1053
-
1054
-
Xcode allows you to define custom build settings for each "configuration" (e.g. debug, release), which can then be referenced as the value of keys within the `Info.plist` file. This mechanism allows you to easily configure your debug builds to use your CodePush staging deployment key, and your release builds to use your CodePush production deployment key.
1055
-
1056
-
To set this up, perform the following steps:
1057
-
1058
-
1. Open up your Xcode project and select your project in the `Project navigator` window
1059
-
1060
-
2. Select the `Build Settings` tab
1061
-
1062
-
3. Click the `+` button on the toolbar and select `Add User-Defined Setting`
4. Name this new setting something like `CODEPUSH_KEY`, expand it, and specify your `Staging` deployment key for the `Debug` config and your `Production` deployment key for the `Production` config.
And that's it! Now when you run or build your app, your debug builds will automatically be configured to sync with your `Staging` deployment, and your release builds will be configured to sync with your `Production` deployment.
1077
-
1078
-
Additionally, if you want to give them seperate names and/or icons, you can modify the `Product Name` and `Asset Catalog App Icon Set Name` build settings, so that the debug configuration has a unique value.
In addition to being able to use the CodePush CLI to "manually" release updates, we believe that it's important to create a repeatable and sustainable solution for contiously delivering updates to your app. That way, it's simple enough for you and/or your team to create and maintain the rhythm of performing agile deployments. In order to assist with seting up a CodePush-based CD pipeline, refer to the following integrations with various CI servers:
0 commit comments