diff --git a/README.md b/README.md index c349074ed..ed1d50c31 100644 --- a/README.md +++ b/README.md @@ -264,7 +264,7 @@ Taking advantage of the `Staging` and `Production` deployments allows you to ach *NOTE: If you want to get really fancy, you can even choose to perform a "staged rollout" as part of #3, which allows you to mitigate additional potential risk with the update (e.g. did your testing in #2 touch all possible devices/conditions?) by only making the production update available to a percentage of your users (e.g. `code-push promote Staging Production -r 20%`). Then, after waiting for a reasonable amount of time to see if any crash reports or customer feedback comes in, you can expand it to your entire audience by running `code-push patch Production -r 100%`.* -You'll notice that the above steps refer to a "staging build" and "production build" of your app. If your build process already generates distinct binaries per "environment", then you don't need to read any further, since swapping out CodePush deployment keys is just like handling environment-specific config for any other service your app uses (e.g. Facebook). However, if you're looking for examples on how to setup your build process to accommodate this, then refer to the following sections, depending on the platform(s) your app is targeting: +You'll notice that the above steps refer to a "staging build" and "production build" of your app. If your build process already generates distinct binaries per "environment", then you don't need to read any further, since swapping out CodePush deployment keys is just like handling environment-specific config for any other service your app uses (e.g. Facebook). However, if you're looking for examples (**including demo projects**) on how to setup your build process to accommodate this, then refer to the following sections, depending on the platform(s) your app is targeting: * [Android](docs/multi-deployment-testing-android.md) * [iOS](docs/multi-deployment-testing-ios.md) diff --git a/docs/multi-deployment-testing-android.md b/docs/multi-deployment-testing-android.md index 461f04b41..53a0c4460 100644 --- a/docs/multi-deployment-testing-android.md +++ b/docs/multi-deployment-testing-android.md @@ -1,5 +1,9 @@ ### Android +> NOTE +> +> Complete demo configured with "multi-deployment testing" feature is [here](https://github.com/Microsoft/react-native-code-push/files/1314118/rncp1004.zip). + 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. To set this up, perform the following steps: diff --git a/docs/multi-deployment-testing-ios.md b/docs/multi-deployment-testing-ios.md index 5d57eaf3d..c13818b76 100644 --- a/docs/multi-deployment-testing-ios.md +++ b/docs/multi-deployment-testing-ios.md @@ -1,5 +1,11 @@ ### iOS +> NOTE +> +> Complete demos configured with "multi-deployment testing" feature are [here]: +> * **without using cocoa pods**: [link](https://github.com/Microsoft/react-native-code-push/files/1259957/rncp976.copy.zip) +> * **using cocoa pods**: [link](https://github.com/Microsoft/react-native-code-push/files/1172217/rncp893.copy.zip) + 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 (e.g. the `CodePushDeploymentKey` setting). This mechanism allows you to easily configure your builds to produce binaries, which are configured to synchronize with different CodePush deployments. To set this up, perform the following steps: