@revopush/code-push-cli 0.0.1 → 0.0.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +304 -617
- package/README_MS.md +837 -0
- package/bin/script/cli.js +0 -0
- package/bin/script/command-executor.js +14 -15
- package/bin/script/command-parser.js +42 -27
- package/bin/script/management-sdk.js +5 -4
- package/guied.md +351 -0
- package/package.json +7 -3
- package/script/command-executor.ts +28 -36
- package/script/command-parser.ts +51 -32
- package/script/management-sdk.ts +5 -4
- package/script/types/cli.ts +3 -1
- package/.idea/cli.iml +0 -9
- package/.idea/inspectionProfiles/Project_Default.xml +0 -6
- package/.idea/misc.xml +0 -6
- package/.idea/modules.xml +0 -8
- package/.idea/prettier.xml +0 -6
- package/.idea/vcs.xml +0 -6
package/README.md
CHANGED
|
@@ -1,774 +1,461 @@
|
|
|
1
|
-
|
|
2
|
-
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
1
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
1
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
##
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
1
|
+
**Guide Overview:**
|
|
2
|
+
1. [Introduction](#1-introduction)
|
|
3
|
+
2. [Prerequisites](#2-prerequisites)
|
|
4
|
+
- 2.1 [Installing Required Tools](#21-installing-required-tools)
|
|
5
|
+
- 2.2 [Setting Up Revopush CLI](#22-setting-up-revopush-cli)
|
|
6
|
+
3. [Migrating from Appcenter to Revopush](#3-migrating-from-appcenter-to-revopush)
|
|
7
|
+
- 3.1 [Logging In](#31-logging-in)
|
|
8
|
+
- 3.2 [Migrating Applications and Deployments](#32-migrating-applications-and-deployments)
|
|
9
|
+
4. [Setting Up Revopush from Scratch](#4-setting-up-revopush-from-scratch)
|
|
10
|
+
- 4.1 [Logging In](#41-logging-in)
|
|
11
|
+
- 4.2 [Creating Applications](#42-creating-applications)
|
|
12
|
+
- 4.3 [Creating Deployments](#43-creating-deployments)
|
|
13
|
+
5. [Updating Your React Native App](#5-updating-your-react-native-app)
|
|
14
|
+
- 5.1 [iOS Configuration](#51-ios-configuration)
|
|
15
|
+
- 5.2 [Android Configuration](#52-android-configuration)
|
|
16
|
+
6. [Releasing Updates](#6-releasing-updates)
|
|
17
|
+
- 6.1 [For iOS](#61-for-ios)
|
|
18
|
+
- 6.2 [For Android](#62-for-android)
|
|
19
|
+
- 6.3 [Additional Options](#63-additional-options)
|
|
20
|
+
7. [Summary and Resources](#7-summary-and-resources)
|
|
21
|
+
|
|
22
|
+
## 1. Introduction
|
|
23
|
+
|
|
24
|
+
Welcome! This guide will help you migrate your Over-the-Air (OTA) updates from Appcenter to Revopush.
|
|
25
|
+
With Revopush's Command Line Interface (CLI), you can easily push updates directly to your users' devices
|
|
26
|
+
without needing to go through app stores.
|
|
27
|
+
|
|
28
|
+
**What You'll Learn:**
|
|
29
|
+
- How to install the Revopush CLI
|
|
30
|
+
- Migrating your existing OTA updates from Appcenter
|
|
31
|
+
- Setting up and managing your applications and deployments in Revopush
|
|
32
|
+
- Updating your React Native app to use Revopush for OTA updates
|
|
33
|
+
|
|
34
|
+
Let’s get started!
|
|
35
|
+
|
|
36
|
+
## 2. Prerequisites
|
|
37
|
+
|
|
38
|
+
Before you begin, ensure you have the following (depends on your platform and preferences):
|
|
39
|
+
|
|
40
|
+
- **Developer Tools Installed:**
|
|
41
|
+
- [Node.js](https://nodejs.org/)
|
|
42
|
+
- npm or Yarn
|
|
43
|
+
- npx
|
|
44
|
+
- [Android Studio](https://developer.android.com/studio)
|
|
45
|
+
- [Xcode](https://developer.apple.com/xcode/)
|
|
46
|
+
- [Visual Studio Code](https://code.visualstudio.com/)
|
|
47
|
+
|
|
48
|
+
- **Permissions:**
|
|
49
|
+
- Ability to install npm packages globally.
|
|
50
|
+
|
|
51
|
+
- **Revopush Account:**
|
|
52
|
+
- Sign up at [Revopush](https://revopush.org/) using GitHub or Google for authentication.
|
|
53
|
+
|
|
54
|
+
- **(If Migrating) Appcenter Access:**
|
|
55
|
+
- Ensure you have access to your existing Appcenter account and its CLI.
|
|
56
|
+
|
|
57
|
+
### 2.1 Installing Required Tools
|
|
58
|
+
You manage most of CodePush's functionality using the App Center CLI.
|
|
59
|
+
If you had one installed, you can update it to the latest version by running the following command:
|
|
49
60
|
|
|
50
61
|
```shell
|
|
51
|
-
|
|
62
|
+
npm update -g appcenter
|
|
52
63
|
```
|
|
53
64
|
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
If at any time you want to determine if you're already logged in, you can run the following command to display the e-mail address associated with your current authentication session, which identity providers your account is linked to (e.g. GitHub):
|
|
65
|
+
or install it from scratch by running the following command:
|
|
57
66
|
|
|
58
67
|
```shell
|
|
59
|
-
|
|
68
|
+
npm install -g appcenter@latest
|
|
60
69
|
```
|
|
61
70
|
|
|
62
|
-
|
|
71
|
+
Upon installation or update, you can check the version of the App Center CLI by running the following command:
|
|
63
72
|
|
|
64
73
|
```shell
|
|
65
|
-
|
|
74
|
+
appcenter -h
|
|
66
75
|
```
|
|
67
76
|
|
|
68
|
-
|
|
77
|
+
which will display the version of the App Center CLI you have installed with available commands.
|
|
69
78
|
|
|
70
79
|
```shell
|
|
71
|
-
|
|
72
|
-
code-push-standalone session rm <machineName>
|
|
73
|
-
```
|
|
80
|
+
$ appcenter -h
|
|
74
81
|
|
|
75
|
-
|
|
82
|
+
Visual Studio App Center helps you build, test, distribute, and monitor mobile apps.
|
|
83
|
+
Version 3.0.3
|
|
76
84
|
|
|
77
|
-
|
|
85
|
+
Usage: appcenter <command>
|
|
78
86
|
|
|
79
|
-
|
|
80
|
-
|
|
87
|
+
Commands:
|
|
88
|
+
analytics View events, audience info, sessions, and other analytics for apps
|
|
89
|
+
apps View and manage apps
|
|
90
|
+
build Start builds, get their status, and download artifacts
|
|
91
|
+
codepush View and manage CodePush deployments and releases
|
|
92
|
+
crashes Upload symbols for better crash reports
|
|
93
|
+
distribute Send builds to testers and manage distribution groups
|
|
94
|
+
orgs Manage organizations
|
|
95
|
+
profile Manage your profile
|
|
96
|
+
telemetry Manage telemetry preferences
|
|
97
|
+
test Start test runs and get their status
|
|
98
|
+
tokens Manage API tokens
|
|
99
|
+
help Get help using appcenter commands
|
|
100
|
+
login Log in
|
|
101
|
+
logout Log out
|
|
102
|
+
setup-autocomplete Setup tab completion for your shell
|
|
81
103
|
```
|
|
82
104
|
|
|
83
|
-
|
|
105
|
+
### 2.2 Setting Up Revopush CLI
|
|
106
|
+
Similarly to Appcenter Revopush manages the most of CodePush's functionality using CLI.
|
|
84
107
|
|
|
85
|
-
|
|
108
|
+
To install it run the following command:
|
|
86
109
|
|
|
110
|
+
**Install Revopush CLI:**
|
|
87
111
|
```shell
|
|
88
|
-
code-push-
|
|
112
|
+
npm install -g @revopush/code-push-cli
|
|
89
113
|
```
|
|
90
114
|
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
Finally, if at any point you need to change a key's name and/or expiration date, you can use the following command:
|
|
94
|
-
|
|
115
|
+
**Update Revopush CLI to the Latest Version:**
|
|
95
116
|
```shell
|
|
96
|
-
code-push-
|
|
97
|
-
```
|
|
98
|
-
|
|
99
|
-
_NOTE: When patching the TTL of an existing access key, its expiration date will be set relative to the current time, with no regard for its previous value._
|
|
100
|
-
|
|
101
|
-
## App Management
|
|
102
|
-
|
|
103
|
-
Before you can deploy any updates, you need to register an app with the CodePush service using the following command:
|
|
104
|
-
|
|
105
|
-
```
|
|
106
|
-
code-push-standalone app add <appName>
|
|
117
|
+
npm update -g @revopush/code-push-cli
|
|
107
118
|
```
|
|
108
119
|
|
|
109
|
-
|
|
120
|
+
Upon installation or update, you can check the version of the Revopush CLI and the list of available commands by running the following command:
|
|
110
121
|
|
|
111
|
-
|
|
112
|
-
|
|
113
|
-
|
|
122
|
+
**Verify Installation:**
|
|
123
|
+
```shell
|
|
124
|
+
revopush -h
|
|
114
125
|
```
|
|
115
126
|
|
|
116
|
-
|
|
127
|
+
which will display the version of the Revopush CLI you have installed with available commands.
|
|
117
128
|
|
|
118
|
-
|
|
119
|
-
|
|
120
|
-
|
|
129
|
+
```shell
|
|
130
|
+
revopush -h
|
|
131
|
+
____ ____ _
|
|
132
|
+
| _ \ _____ _____ | _ \ _ _ ___| |__
|
|
133
|
+
| |_) / _ \ \ / / _ \| |_) | | | / __| '_ \
|
|
134
|
+
| _ < __/\ V / (_) | __/| |_| \__ \ | | |
|
|
135
|
+
|_| \_\___| \_/ \___/|_| \__,_|___/_| |_| CLI v0.0.1
|
|
136
|
+
============================================
|
|
137
|
+
Revopush is a service that enables you to deploy mobile app updates directly to your users devices. Visit our website https://revopush.org/
|
|
121
138
|
|
|
122
|
-
|
|
123
|
-
code-push-standalone app rename <appName> <newAppName>
|
|
124
|
-
```
|
|
139
|
+
Usage: revopush <command>
|
|
125
140
|
|
|
126
|
-
|
|
141
|
+
Commands:
|
|
142
|
+
revopush access-key View and manage the access keys associated with your account
|
|
143
|
+
revopush app View and manage your CodePush apps
|
|
144
|
+
revopush collaborator View and manage app collaborators
|
|
145
|
+
revopush debug View the CodePush debug logs for a running app
|
|
146
|
+
revopush deployment View and manage your app deployments
|
|
147
|
+
revopush login Authenticate with the CodePush server in order to begin managing your apps
|
|
148
|
+
revopush logout Log out of the current session
|
|
149
|
+
revopush patch Update the metadata for an existing release
|
|
150
|
+
revopush promote Promote the latest release from one app deployment to another
|
|
151
|
+
revopush register Register a new CodePush account
|
|
152
|
+
revopush release Release an update to an app deployment
|
|
153
|
+
revopush release-react Release a React Native update to an app deployment
|
|
154
|
+
revopush rollback Rollback the latest release for an app deployment
|
|
155
|
+
revopush session View and manage the current login sessions associated with your account
|
|
156
|
+
revopush whoami Display the account info for the current login session
|
|
127
157
|
|
|
128
|
-
|
|
158
|
+
Options:
|
|
159
|
+
--help Show help [boolean]
|
|
160
|
+
-v, --version Show version number [boolean]
|
|
129
161
|
|
|
130
|
-
```
|
|
131
|
-
code-push-standalone app rm <appName>
|
|
132
162
|
```
|
|
133
163
|
|
|
134
|
-
|
|
164
|
+
## 3. Migrating from Appcenter to Revopush
|
|
135
165
|
|
|
136
|
-
|
|
137
|
-
you can run the following command:
|
|
166
|
+
You need to execute steps in this section if you have been using Appcenter for OTA updates and wish to migrate to Revopush.
|
|
138
167
|
|
|
139
|
-
|
|
140
|
-
|
|
141
|
-
```
|
|
168
|
+
If you did not use Appcenter OTA updates before and just wish to apply
|
|
169
|
+
OTA on top of Revopush for your app feel free to skip this section and go to section [4](#4-setting-up-revopush-from-scratch).
|
|
142
170
|
|
|
143
|
-
###
|
|
171
|
+
### 3.1 Logging In
|
|
144
172
|
|
|
145
|
-
|
|
173
|
+
Execute the following command to login to Appcenter CLI using provider of your choice (GitHub, Facebook, Microsoft, Google):
|
|
146
174
|
|
|
147
175
|
```shell
|
|
148
|
-
|
|
176
|
+
appcenter login
|
|
149
177
|
```
|
|
150
178
|
|
|
151
|
-
|
|
152
|
-
|
|
153
|
-
Once added, all collaborators will immediately have the following permissions with regards to the newly shared app:
|
|
154
|
-
|
|
155
|
-
1. View the app, its collaborators, [deployments](#deployment-management) and [release history](#viewing-release-history)
|
|
156
|
-
1. [Release](#releasing-updates) updates to any of the app's deployments
|
|
157
|
-
1. [Promote](#promoting-updates) an update between any of the app's deployments
|
|
158
|
-
1. [Rollback](#rolling-back-undesired-updates) any of the app's deployments
|
|
159
|
-
1. [Patch](#updating-existing-releases) any releases within any of the app's deployments
|
|
160
|
-
|
|
161
|
-
Inversely, that means that an app collaborator cannot do any of the following:
|
|
162
|
-
|
|
163
|
-
1. Rename or delete the app
|
|
164
|
-
1. Transfer ownership of the app
|
|
165
|
-
1. Create, rename or delete new deployments within the app
|
|
166
|
-
1. Clear a deployment's release history
|
|
167
|
-
1. Add or remove collaborators from the app (\*)
|
|
168
|
-
|
|
169
|
-
_NOTE: A developer can remove him/herself as a collaborator from an app that was shared with them._
|
|
170
|
-
|
|
171
|
-
Over time, if someone is no longer working on an app with you, you can remove them as a collaborator using the following command:
|
|
179
|
+
Similarly, in a separate window login to Revopush CLI using the following command:
|
|
172
180
|
|
|
173
181
|
```shell
|
|
174
|
-
|
|
182
|
+
revopush login
|
|
175
183
|
```
|
|
176
184
|
|
|
177
|
-
|
|
185
|
+
### 3.2 Migrating Applications and Deployments
|
|
186
|
+
**1. List Your Appcenter Apps:**
|
|
178
187
|
|
|
179
188
|
```shell
|
|
180
|
-
|
|
189
|
+
appcenter apps list
|
|
181
190
|
```
|
|
182
191
|
|
|
183
|
-
|
|
192
|
+
Example Output:
|
|
184
193
|
|
|
185
194
|
```shell
|
|
186
|
-
|
|
195
|
+
johndoe/rn2_android
|
|
196
|
+
johndoe/rn2_ios
|
|
187
197
|
```
|
|
188
198
|
|
|
189
|
-
|
|
190
|
-
|
|
191
|
-
Once confirmed, the specified developer becomes the app's owner and immediately receives the permissions associated with that role. Besides the transfer of ownership, nothing else about the app is modified (e.g. deployments, release history, collaborators). This means that you will still be a collaborator of the app, and therefore, if you want to remove yourself, you simply need to run the `code-push-standalone collaborator rm` command after successfully transferring ownership.
|
|
199
|
+
For given guide we assume that `johndoe/rn2_android` is the React Native application for Android and `johndoe/rn2_ios`
|
|
200
|
+
is the React Native application for iOS.
|
|
192
201
|
|
|
193
|
-
|
|
194
|
-
|
|
195
|
-
From the CodePush perspective, an app is simply a named grouping for one or more things called "deployments". While the app represents a conceptual "namespace" or "scope" for a platform-specific version of an app (e.g. the iOS port of Foo app), its deployments represent the actual target for releasing updates (for developers) and synchronizing updates (for end-users). Deployments allow you to have multiple "environments" for each app in-flight at any given time, and help model the reality that apps typically move from a dev's personal environment to a testing/QA/staging environment, before finally making their way into production.
|
|
196
|
-
|
|
197
|
-
_NOTE: As you'll see below, the `release`, `promote` and `rollback` commands require both an app name and a deployment name is order to work, because it is the combination of the two that uniquely identifies a point of distribution (e.g. I want to release an update of my iOS app to my beta testers)._
|
|
198
|
-
|
|
199
|
-
Whenever an app is registered with the CodePush service, it includes two deployments by default: `Staging` and `Production`. This allows you to immediately begin releasing updates to an internal environment, where you can thoroughly test each update before pushing them out to your end-users. This workflow is critical for ensuring your releases are ready for mass-consumption, and is a practice that has been established in the web for a long time.
|
|
200
|
-
|
|
201
|
-
If having a staging and production version of your app is enough to meet your needs, then you don't need to do anything else. However, if you want an alpha, dev, etc. deployment, you can easily create them using the following command:
|
|
202
|
-
|
|
203
|
-
```
|
|
204
|
-
code-push-standalone deployment add <appName> <deploymentName>
|
|
205
|
-
```
|
|
202
|
+
You can check target OS of the app using command `appcenter apps show -a <app name here>`.
|
|
206
203
|
|
|
207
|
-
|
|
204
|
+
**Android:**
|
|
208
205
|
|
|
209
|
-
```
|
|
210
|
-
|
|
211
|
-
|
|
212
|
-
|
|
213
|
-
|
|
214
|
-
|
|
206
|
+
```shell
|
|
207
|
+
appcenter apps show -a johndoe/rn2_android
|
|
208
|
+
App Secret: 6c3cb412-105f-422f-b795-af53d0b36a5f
|
|
209
|
+
Description:
|
|
210
|
+
Display Name: rn2_android
|
|
211
|
+
Name: rn2_android
|
|
212
|
+
OS: Android
|
|
213
|
+
Platform: React-Native
|
|
214
|
+
Release Type: Alpha
|
|
215
|
+
Owner ID: a1265e53-0599-4340-8003-7c40f0caff38
|
|
216
|
+
Owner Display Name: John Doe
|
|
217
|
+
Owner Email: johndoe@joghdoe.com
|
|
218
|
+
Owner Name: johndoe
|
|
219
|
+
Azure Subscription ID:
|
|
220
|
+
```
|
|
221
|
+
|
|
222
|
+
**iOS:**
|
|
215
223
|
|
|
224
|
+
```shell
|
|
225
|
+
appcenter apps show -a johndoe/rn2_ios
|
|
226
|
+
App Secret: 37d1dce7-a991-4ccc-8a0c-1ff8ed00f45d
|
|
227
|
+
Description:
|
|
228
|
+
Display Name: rn2_ios
|
|
229
|
+
Name: rn2_ios
|
|
230
|
+
OS: iOS
|
|
231
|
+
Platform: React-Native
|
|
232
|
+
Release Type:
|
|
233
|
+
Owner ID: a2265e53-0699-4340-8003-7c41f0caff39
|
|
234
|
+
Owner Display Name: John Doe
|
|
235
|
+
Owner Email: johndoe@johndoe.com
|
|
236
|
+
Owner Name: johndoe
|
|
237
|
+
Azure Subscription ID:
|
|
216
238
|
```
|
|
217
|
-
code-push-standalone deployment ls <appName> [--displayKeys|-k]
|
|
218
|
-
```
|
|
219
|
-
|
|
220
|
-
This will display not only the list of deployments, but also the update metadata (e.g. mandatory, description) and installation metrics for their latest release:
|
|
221
|
-
|
|
222
|
-
|
|
223
|
-
|
|
224
|
-
_NOTE: Due to their infrequent use and needed screen real estate, deployment keys aren't displayed by default. If you need to view them, simply make sure to pass the `-k` flag to the `deployment ls` command._
|
|
225
|
-
|
|
226
|
-
The install metrics have the following meaning:
|
|
227
|
-
|
|
228
|
-
- **Active** - The number of successful installs that are currently running this release (i.e. if the user opened your app, they would see/run this version). This number will increase and decrease as end-users upgrade to and away from this release, respectively. This metric shows both the total of active users, as well as what percentage of your overall audience that represents. This makes it easy to determine the distribution of updates that your users are currently running, as well as answer questions such as "How many of my users have received my latest update?".
|
|
229
|
-
|
|
230
|
-
- **Total** - The total number of successful installations that this update has received overall. This number only ever increases as new users/devices install it, and therefore, this is always a superset of the total active count. An update is considered successful once `notifyApplicationReady` (or `sync`) is called after it was installed. Between the moment that an update is downloaded, and it is marked as being successful, it will be reported as a "pending" update (see below for details).
|
|
231
|
-
|
|
232
|
-
- **Pending** - The number of times this release has been downloaded, but not yet installed (i.e. the app was restarted to apply the changes). Therefore, this metric increases as updates are downloaded, and decreases as those corresponding downloaded updates are installed. This metric primarily applies to updates that aren't configured to install immediately, and helps provide the broader picture of release adoption for apps that rely on app resume and/or restart to apply an update (e.g. I want to rollback an update and I'm curious if anyone has downloaded it yet). If you've configured updates to install immediately, and are still seeing pending updates being reported, then it's likely that you're not calling `notifyApplicationReady` (or `sync`) on app start, which is the method that initiates sending install reports and marks installed updates as being considered successful.
|
|
233
|
-
|
|
234
|
-
- **Rollbacks** - The number of times that this release has been automatically rolled back on the client. Ideally this number should be zero, and in that case, this metric isn't even shown. However, if you released an update that includes a crash as part of the installation process, the CodePush plugin will roll the end-user back to the previous release, and report that issue back to the server. This allows your end-users to remain unblocked in the event of broken releases, and by being able to see this telemetry in the CLI, you can identify erroneous releases and respond to them by [rolling it back](#rolling-back-undesired-updates) on the server.
|
|
235
239
|
|
|
236
|
-
- **Rollout** - Indicates the percentage of users that are eligible to receive this update. This property will only be displayed for releases that represent an "active" rollout, and therefore, have a rollout percentage that is less than 100%. Additionally, since a deployment can only have one active rollout at any given time, this label would only be present on the latest release within a deployment.
|
|
237
240
|
|
|
238
|
-
|
|
241
|
+
**2. Create Corresponding Revopush Apps:**
|
|
239
242
|
|
|
240
|
-
|
|
243
|
+
Remove the username prefix when creating apps in Revopush.
|
|
241
244
|
|
|
242
|
-
|
|
243
|
-
|
|
244
|
-
|
|
245
|
-
|
|
246
|
-
1. [General](#releasing-updates-general) - Releases an update to the CodePush server that was generated by an external tool or build script (e.g. a Gulp task, the `react-native bundle` command). This provides the most flexibility in terms of fitting into existing workflows, since it strictly deals with CodePush-specific step, and leaves the app-specific compilation process to you.
|
|
247
|
-
|
|
248
|
-
2. [React Native](#releasing-updates-react-native) - Performs the same functionality as the general release command, but also handles the task of generating the updated app contents for you (JS bundle and assets), instead of requiring you to run both `react-native bundle` and then `code-push-standalone release`.
|
|
249
|
-
|
|
250
|
-
Which of these commands you should use is mostly a matter of requirements and/or preference. However, we generally recommend using the platform-specific command to start (since it greatly simplifies the experience), and then leverage the general-purpose `release` command if/when greater control is needed.
|
|
251
|
-
|
|
252
|
-
### Releasing Updates (General)
|
|
253
|
-
|
|
254
|
-
```
|
|
255
|
-
code-push-standalone release <appName> <updateContents> <targetBinaryVersion>
|
|
256
|
-
[--deploymentName <deploymentName>]
|
|
257
|
-
[--description <description>]
|
|
258
|
-
[--disabled <disabled>]
|
|
259
|
-
[--mandatory]
|
|
260
|
-
[--noDuplicateReleaseError]
|
|
261
|
-
[--rollout <rolloutPercentage>]
|
|
245
|
+
```shell
|
|
246
|
+
revopush app add rn2_ios
|
|
247
|
+
revopush app add rn2_android
|
|
262
248
|
```
|
|
263
249
|
|
|
264
|
-
|
|
265
|
-
|
|
266
|
-
This specifies the name of the CodePush app that this update is being released for. This value corresponds to the friendly name that you specified when originally calling `code-push-standalone app add` (e.g. "MyApp-Android"). If you need to look it up, you can run the `code-push-standalone app ls` command to see your list of apps.
|
|
267
|
-
|
|
268
|
-
#### Update contents parameter
|
|
269
|
-
|
|
270
|
-
This specifies the location of the updated app code and assets you want to release. You can provide either a single file (e.g. a JS bundle for a React Native app), or a path to a directory. Note that you don't need to ZIP up multiple files or directories in order to deploy those changes, since the CLI will automatically ZIP them for you.
|
|
271
|
-
|
|
272
|
-
It's important that the path you specify refers to the platform-specific, prepared/bundled version of your app. The following table outlines which command you should run before releasing, as well as the location you can subsequently refer to using the `updateContents` parameter:
|
|
273
|
-
|
|
274
|
-
| Platform | Prepare command | Package path (relative to project root) |
|
|
275
|
-
| -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
|
|
276
|
-
| React Native wo/assets (Android) | `react-native bundle --platform android --entry-file <entryFile> --bundle-output <bundleOutput> --dev false` | Value of the `--bundle-output` option |
|
|
277
|
-
| React Native w/assets (Android) | `react-native bundle --platform android --entry-file <entryFile> --bundle-output <releaseFolder>/<bundleOutput> --assets-dest <releaseFolder> --dev false` | Value of the `--assets-dest` option, which should represent a newly created directory that includes your assets and JS bundle |
|
|
278
|
-
| React Native wo/assets (iOS) | `react-native bundle --platform ios --entry-file <entryFile> --bundle-output <bundleOutput> --dev false` | Value of the `--bundle-output` option |
|
|
279
|
-
| React Native w/assets (iOS) | `react-native bundle --platform ios --entry-file <entryFile> --bundle-output <releaseFolder>/<bundleOutput> --assets-dest <releaseFolder> --dev false` | Value of the `--assets-dest` option, which should represent a newly created directory that includes your assets and JS bundle |
|
|
280
|
-
|
|
281
|
-
#### Target binary version parameter
|
|
282
|
-
|
|
283
|
-
This specifies the store/binary version of the application you are releasing the update for, so that only users running that version will receive the update, while users running an older and/or newer version of the app binary will not. This is useful for the following reasons:
|
|
284
|
-
|
|
285
|
-
1. If a user is running an older binary version, it's possible that there are breaking changes in the CodePush update that wouldn't be compatible with what they're running.
|
|
286
|
-
|
|
287
|
-
2. If a user is running a newer binary version, then it's presumed that what they are running is newer (and potentially incompatible) with the CodePush update.
|
|
288
|
-
|
|
289
|
-
If you ever want an update to target multiple versions of the app store binary, we also allow you to specify the parameter as a [semver range expression](https://github.com/npm/node-semver#advanced-range-syntax). That way, any client device running a version of the binary that satisfies the range expression (i.e. `semver.satisfies(version, range)` returns `true`) will get the update. Examples of valid semver range expressions are as follows:
|
|
290
|
-
|
|
291
|
-
| Range Expression | Who gets the update |
|
|
292
|
-
| ---------------- | -------------------------------------------------------------------------------------- |
|
|
293
|
-
| `1.2.3` | Only devices running the specific binary app store version `1.2.3` of your app |
|
|
294
|
-
| `*` | Any device configured to consume updates from your CodePush app |
|
|
295
|
-
| `1.2.x` | Devices running major version 1, minor version 2 and any patch version of your app |
|
|
296
|
-
| `1.2.3 - 1.2.7` | Devices running any binary version between `1.2.3` (inclusive) and `1.2.7` (inclusive) |
|
|
297
|
-
| `>=1.2.3 <1.2.7` | Devices running any binary version between `1.2.3` (inclusive) and `1.2.7` (exclusive) |
|
|
298
|
-
| `~1.2.3` | Equivalent to `>=1.2.3 <1.3.0` |
|
|
299
|
-
| `^1.2.3` | Equivalent to `>=1.2.3 <2.0.0` |
|
|
300
|
-
|
|
301
|
-
_NOTE: If your semver expression starts with a special shell character or operator such as `>`, `^`, or \*\*
|
|
302
|
-
_, the command may not execute correctly if you do not wrap the value in quotes as the shell will not supply the right values to our CLI process. Therefore, it is best to wrap your `targetBinaryVersion` parameter in double quotes when calling the `release` command, e.g. `code-push-standalone release MyApp-iOS updateContents ">1.2.3"`.\*
|
|
303
|
-
|
|
304
|
-
_NOTE: As defined in the semver spec, ranges only work for non pre-release versions: https://github.com/npm/node-semver#prerelease-tags. If you want to update a version with pre-release tags, then you need to write the exact version you want to update (`1.2.3-beta` for example)._
|
|
305
|
-
|
|
306
|
-
The following table outlines the version value that CodePush expects your update's semver range to satisfy for each respective app type:
|
|
307
|
-
|
|
308
|
-
| Platform | Source of app store version |
|
|
309
|
-
| ---------------------- | ---------------------------------------------------------------------------- |
|
|
310
|
-
| React Native (Android) | The `android.defaultConfig.versionName` property in your `build.gradle` file |
|
|
311
|
-
| React Native (iOS) | The `CFBundleShortVersionString` key in the `Info.plist` file |
|
|
312
|
-
| React Native (Windows) | The `<Identity Version>` key in the `Package.appxmanifest` file |
|
|
313
|
-
|
|
314
|
-
_NOTE: If the app store version in the metadata files are missing a patch version, e.g. `2.0`, it will be treated as having a patch version of `0`, i.e. `2.0 -> 2.0.0`._
|
|
315
|
-
|
|
316
|
-
#### Deployment name parameter
|
|
317
|
-
|
|
318
|
-
This specifies which deployment you want to release the update to. This defaults to `Staging`, but when you're ready to deploy to `Production`, or one of your own custom deployments, just explicitly set this argument.
|
|
319
|
-
|
|
320
|
-
_NOTE: The parameter can be set using either "--deploymentName" or "-d"._
|
|
321
|
-
|
|
322
|
-
#### Description parameter
|
|
323
|
-
|
|
324
|
-
This provides an optional "change log" for the deployment. The value is simply round tripped to the client so that when the update is detected, your app can choose to display it to the end-user (e.g. via a "What's new?" dialog). This string accepts control characters such as `\n` and `\t` so that you can include whitespace formatting within your descriptions for improved readability.
|
|
325
|
-
|
|
326
|
-
_NOTE: This parameter can be set using either "--description" or "-des"_
|
|
327
|
-
|
|
328
|
-
#### Disabled parameter
|
|
329
|
-
|
|
330
|
-
This specifies whether an update should be downloadable by end users or not. If left unspecified, the update will not be disabled (i.e. users will download it the moment your app calls `sync`). This parameter can be valuable if you want to release an update that isn't immediately available, until you explicitly [patch it](#patching-releases) when you want end users to be able to download it (e.g. an announcement blog post went live).
|
|
331
|
-
|
|
332
|
-
_NOTE: This parameter can be set using either "--disabled" or "-x"_
|
|
333
|
-
|
|
334
|
-
#### Mandatory parameter
|
|
335
|
-
|
|
336
|
-
This specifies whether the update should be considered mandatory or not (e.g. it includes a critical security fix). This attribute is simply round tripped to the client, who can then decide if and how they would like to enforce it.
|
|
337
|
-
|
|
338
|
-
_NOTE: This parameter is simply a "flag", and therefore, its absence indicates that the release is optional, and its presence indicates that it's mandatory. You can provide a value to it (e.g. `--mandatory true`), however, simply specifying `--mandatory` is sufficient for marking a release as mandatory._
|
|
339
|
-
|
|
340
|
-
The mandatory attribute is unique because the server will dynamically modify it as necessary in order to ensure that the semantics of your releases are maintained for your end-users. For example, imagine that you released the following three updates to your app:
|
|
341
|
-
|
|
342
|
-
| Release | Mandatory? |
|
|
343
|
-
| ------- | ---------- |
|
|
344
|
-
| v1 | No |
|
|
345
|
-
| v2 | Yes |
|
|
346
|
-
| v3 | No |
|
|
347
|
-
|
|
348
|
-
If an end-user is currently running `v1`, and they query the server for an update, it will respond with `v3` (since that is the latest), but it will dynamically convert the release to mandatory, since a mandatory update was released in between. This behavior is important since the code contained in `v3` is incremental to that included in `v2`, and therefore, whatever made `v2` mandatory, continues to make `v3` mandatory for anyone that didn't already acquire `v2`.
|
|
349
|
-
|
|
350
|
-
If an end-user is currently running `v2`, and they query the server for an update, it will respond with `v3`, but leave the release as optional. This is because they already received the mandatory update, and therefore, there isn't a need to modify the policy of `v3`. This behavior is why we say that the server will "dynamically convert" the mandatory flag, because as far as the release goes, its mandatory attribute will always be stored using the value you specified when releasing it. It is only changed on-the-fly as necessary when responding to an update check from an end-user.
|
|
351
|
-
|
|
352
|
-
If you never release an update that is marked as mandatory, then the above behavior doesn't apply to you, since the server will never change an optional release to mandatory unless there were intermingled mandatory updates as illustrated above. Additionally, if a release is marked as mandatory, it will never be converted to optional, since that wouldn't make any sense. The server will only change an optional release to mandatory in order to respect the semantics described above.
|
|
353
|
-
|
|
354
|
-
_NOTE: This parameter can be set using either `--mandatory` or `-m`_
|
|
355
|
-
|
|
356
|
-
#### No duplicate release error parameter
|
|
357
|
-
|
|
358
|
-
This specifies that if the update is identical to the latest release on the deployment, the CLI should generate a warning instead of an error. This is useful for continuous integration scenarios where it is expected that small modifications may trigger releases where no production code has changed.
|
|
359
|
-
|
|
360
|
-
#### Rollout parameter
|
|
361
|
-
|
|
362
|
-
**IMPORTANT: In order for this parameter to actually take affect, your end users need to be running version `1.9.0-beta+` (for React Native) of the CodePush plugin. If you release an update that specifies a rollout property, no end user running an older version of React Native plugins will be eligible for the update. Therefore, until you have adopted the neccessary version of the platform-specific CodePush plugin (as previously mentioned), we would advise not setting a rollout value on your releases, since no one would end up receiving it.**
|
|
363
|
-
|
|
364
|
-
This specifies the percentage of users (as an integer between `1` and `100`) that should be eligible to receive this update. It can be helpful if you want to "flight" new releases with a portion of your audience (e.g. 25%), and get feedback and/or watch for exceptions/crashes, before making it broadly available for everyone. If this parameter isn't set, it is set to `100%`, and therefore, you only need to set it if you want to actually limit how many users will receive it.
|
|
365
|
-
|
|
366
|
-
When leveraging the rollout capability, there are a few additional considerations to keep in mind:
|
|
367
|
-
|
|
368
|
-
1. You cannot release a new update to a deployment whose latest release is an "active" rollout (i.e. its rollout property is non-null). The rollout needs to be "completed" (i.e. setting the `rollout` property to `100`) before you can release further updates to the deployment.
|
|
369
|
-
|
|
370
|
-
2. If you rollback a deployment whose latest release is an "active" rollout, the rollout value will be cleared, effectively "deactivating" the rollout behavior
|
|
371
|
-
|
|
372
|
-
3. Unlike the `mandatory` and `description` fields, when you promote a release from one deployment to another, it will not propagate the `rollout` property, and therefore, if you want the new release (in the target deployment) to have a rollout value, you need to explicitly set it when you call the `promote` command.
|
|
373
|
-
|
|
374
|
-
_NOTE: This parameter can be set using either `--rollout` or `-r`_
|
|
375
|
-
|
|
376
|
-
### Releasing Updates (React Native)
|
|
377
|
-
|
|
378
|
-
```shell
|
|
379
|
-
code-push-standalone release-react <appName> <platform>
|
|
380
|
-
[--bundleName <bundleName>]
|
|
381
|
-
[--deploymentName <deploymentName>]
|
|
382
|
-
[--description <description>]
|
|
383
|
-
[--development <development>]
|
|
384
|
-
[--disabled <disabled>]
|
|
385
|
-
[--entryFile <entryFile>]
|
|
386
|
-
[--gradleFile <gradleFile>]
|
|
387
|
-
[--mandatory]
|
|
388
|
-
[--noDuplicateReleaseError]
|
|
389
|
-
[--outputDir <outputDir>]
|
|
390
|
-
[--plistFile <plistFile>]
|
|
391
|
-
[--plistFilePrefix <plistFilePrefix>]
|
|
392
|
-
[--sourcemapOutput <sourcemapOutput>]
|
|
393
|
-
[--targetBinaryVersion <targetBinaryVersion>]
|
|
394
|
-
[--rollout <rolloutPercentage>]
|
|
395
|
-
[--useHermes <useHermes>]
|
|
396
|
-
[--podFile <podFile>]
|
|
397
|
-
[--extraHermesFlags <extraHermesFlags>]
|
|
398
|
-
[--privateKeyPath <privateKeyPath>]
|
|
399
|
-
[--xcodeProjectFile <xcodeProjectFile>]
|
|
400
|
-
[--xcodeTargetName <xcodeTargetName>]
|
|
401
|
-
[--buildConfigurationName <buildConfigurationName>]
|
|
402
|
-
```
|
|
403
|
-
|
|
404
|
-
The `release-react` command is a React Native-specific version of the "vanilla" [`release`](#releasing-app-updates) command, which supports all of the same parameters (e.g. `--mandatory`, `--description`), yet simplifies the process of releasing updates by performing the following additional behavior:
|
|
405
|
-
|
|
406
|
-
1. Running the `react-native bundle` command in order to generate the [update contents](#update-contents-parameter) (JS bundle and assets) that will be released to the CodePush server. It uses sensible defaults as much as possible (e.g. creating a non-dev build, assuming an iOS entry file is named `index.ios.js`), but also exposes the relevant `react-native bundle` parameters to enable flexibility (e.g. `--sourcemapOutput`).
|
|
407
|
-
|
|
408
|
-
2. Inferring the [`targetBinaryVersion`](#target-binary-version-parameter) of this release by using the version name that is specified in your project's `Info.plist` (for iOS) and `build.gradle` (for Android) files.
|
|
409
|
-
|
|
410
|
-
To illustrate the difference that the `release-react` command can make, the following is an example of how you might generate and release an update for a React Native app using the "vanilla" `release` command:
|
|
250
|
+
Example Output:
|
|
411
251
|
|
|
412
252
|
```shell
|
|
413
|
-
|
|
414
|
-
|
|
415
|
-
|
|
416
|
-
|
|
417
|
-
|
|
418
|
-
|
|
419
|
-
|
|
420
|
-
|
|
421
|
-
code-push-standalone release MyApp-iOS ./CodePush 1.0.0
|
|
253
|
+
Successfully added the "rn2_ios" app, along with the following default deployments:
|
|
254
|
+
┌────────────┬────────────────────────────────────────┐
|
|
255
|
+
│ Name │ Deployment Key │
|
|
256
|
+
├────────────┼────────────────────────────────────────┤
|
|
257
|
+
│ Production │ Z7v_81HyATiWlqZjvQFyu9GIicXAVJHvdy5W-g │
|
|
258
|
+
├────────────┼────────────────────────────────────────┤
|
|
259
|
+
│ Staging │ PjAEsKZUdAytb5Rq3Kb6yHVfn-H3VJHvdy5W-g │
|
|
260
|
+
└────────────┴────────────────────────────────────────┘
|
|
422
261
|
```
|
|
423
262
|
|
|
424
|
-
Achieving the equivalent behavior with the `release-react` command would simply require the following command, which is generally less error-prone:
|
|
425
|
-
|
|
426
263
|
```shell
|
|
427
|
-
|
|
264
|
+
Successfully added the "rn2_android" app, along with the following default deployments:
|
|
265
|
+
┌────────────┬────────────────────────────────────────┐
|
|
266
|
+
│ Name │ Deployment Key │
|
|
267
|
+
├────────────┼────────────────────────────────────────┤
|
|
268
|
+
│ Production │ EVGdS0GR4Sus584cdyZ95wmwI405VJHvdy5W-g │
|
|
269
|
+
├────────────┼────────────────────────────────────────┤
|
|
270
|
+
│ Staging │ pkCafa80S-ji3y6Xey6zVcEju9AHVJHvdy5W-g │
|
|
271
|
+
└────────────┴────────────────────────────────────────┘
|
|
428
272
|
```
|
|
429
273
|
|
|
430
|
-
#### App name parameter
|
|
431
|
-
|
|
432
|
-
This is the same parameter as the one described in the [above section](#app-name-parameter).
|
|
433
|
-
|
|
434
|
-
#### Platform parameter
|
|
435
|
-
|
|
436
|
-
This specifies which platform the current update is targeting, and can be either `android`, `ios` or `windows` (case-insensitive). This value is only used to determine how to properly bundle your update contents and isn't actually sent to the server.
|
|
437
|
-
|
|
438
|
-
#### Deployment name parameter
|
|
439
|
-
|
|
440
|
-
This is the same parameter as the one described in the [above section](#deployment-name-parameter).
|
|
441
|
-
|
|
442
|
-
#### Description parameter
|
|
443
|
-
|
|
444
|
-
This is the same parameter as the one described in the [above section](#description-parameter).
|
|
445
|
-
|
|
446
|
-
#### Mandatory parameter
|
|
447
|
-
|
|
448
|
-
This is the same parameter as the one described in the [above section](#mandatory-parameter).
|
|
449
|
-
|
|
450
|
-
#### No duplicate release error parameter
|
|
451
|
-
|
|
452
|
-
This is the same parameter as the one described in the [above section](#no-duplicate-release-error-parameter).
|
|
453
274
|
|
|
454
|
-
|
|
275
|
+
**3. Replicate Deployments:**
|
|
455
276
|
|
|
456
|
-
|
|
457
|
-
|
|
458
|
-
#### Target binary version parameter
|
|
459
|
-
|
|
460
|
-
This is the same parameter as the one described in the [above section](#target-binary-version-parameter). If left unspecified, this defaults to targeting the exact version specified in the app's `Info.plist` (for iOS) and `build.gradle` (for Android) files.
|
|
461
|
-
|
|
462
|
-
#### Bundle name parameter
|
|
463
|
-
|
|
464
|
-
This specifies the file name that should be used for the generated JS bundle. If left unspecified, the standard bundle name will be used for the specified platform: `main.jsbundle` (iOS), `index.android.bundle` (Android) and `index.windows.bundle` (Windows).
|
|
465
|
-
|
|
466
|
-
_NOTE: This parameter can be set using either --bundleName or -b_
|
|
467
|
-
|
|
468
|
-
#### Development parameter
|
|
469
|
-
|
|
470
|
-
This specifies whether to generate a unminified, development JS bundle. If left unspecified, this defaults to `false` where warnings are disabled and the bundle is minified.
|
|
471
|
-
|
|
472
|
-
_NOTE: This parameter can be set using either --development or --dev_
|
|
473
|
-
|
|
474
|
-
#### Disabled parameter
|
|
475
|
-
|
|
476
|
-
This is the same parameter as the one described in the [above section](#disabled-parameter).
|
|
477
|
-
|
|
478
|
-
#### Entry file parameter
|
|
479
|
-
|
|
480
|
-
This specifies the relative path to the app's root/entry JavaScript file. If left unspecified, this defaults to `index.ios.js` (for iOS), `index.android.js` (for Android) or `index.windows.bundle` (for Windows) if that file exists, or `index.js` otherwise.
|
|
481
|
-
|
|
482
|
-
_NOTE: This parameter can be set using either --entryFile or -e_
|
|
483
|
-
|
|
484
|
-
#### Gradle file parameter (Android only)
|
|
485
|
-
|
|
486
|
-
This specifies the relative path to the `build.gradle` file that the CLI should use when attempting to auto-detect the target binary version for the release. This parameter is only meant for advanced scenarios, since the CLI will automatically be able to find your `build.grade` file in "standard" React Native projects. However, if your gradle file is located in an arbitrary location, that the CLI can't discover, then using this parameter allows you to continue releasing CodePush updates, without needing to explicitly set the `--targetBinaryVersion` parameter. Since `build.gradle` is a required file name, specifying the path to the containing folder or the full path to the file itself will both achieve the same effect.
|
|
277
|
+
List Appcenter deployments:
|
|
487
278
|
|
|
488
279
|
```shell
|
|
489
|
-
|
|
490
|
-
code-push-standalone release-react MyApp-Android android -p "./foo/bar/build.gradle"
|
|
280
|
+
appcenter codepush deployment list -k -a johndoe/rn2_ios
|
|
491
281
|
```
|
|
492
282
|
|
|
493
|
-
|
|
494
|
-
|
|
495
|
-
This specifies the relative path to the `Info.plist` file that the CLI should use when attempting to auto-detect the target binary version for the release. This parameter is only meant for advanced scenarios, since the CLI will automatically be able to find your `Info.plist` file in "standard" React Native projects, and you can use the `--plistFilePrefix` parameter in order to support per-environment plist files (e.g. `STAGING-Info.plist`). However, if your plist is located in an arbitrary location, that the CLI can't discover, then using this parameter allows you to continue releasing CodePush updates, without needing to explicitly set the `--targetBinaryVersion` parameter.
|
|
283
|
+
Add the same deployments in Revopush with identical keys
|
|
496
284
|
|
|
497
285
|
```shell
|
|
498
|
-
|
|
286
|
+
revopush deployment add rn2_ios appcenter_Staging -k <Staging_Key>
|
|
287
|
+
revopush deployment add rn2_ios appcenter_Production -k <Production_Key>
|
|
499
288
|
```
|
|
500
289
|
|
|
501
|
-
|
|
502
|
-
|
|
503
|
-
#### Plist file prefix parameter (iOS only)
|
|
504
|
-
|
|
505
|
-
This specifies the file name prefix of the `Info.plist` file that that CLI should use when attempting to auto-detect the target binary version for the release. This can be useful if you've created per-environment plist files (e.g. `DEV-Info.plist`, `STAGING-Info.plist`), and you want to be able to release CodePush updates without needing to explicitly set the `--targetBinaryVersion` parameter. By specifying a `--plistFilePrefx`, the CLI will look for a file named `<prefix>-Info.plist`, instead of simply `Info.plist` (which is the default behavior), in the following locations: `./ios` and `./ios/<appName>`. If your plist file isn't located in either of those directories (e.g. your app is a native iOS app with embedded RN views), or uses an entirely different file naming convention, then consider using the `--plistFile` parameter.
|
|
290
|
+
Repeat for Android
|
|
506
291
|
|
|
507
292
|
```shell
|
|
508
|
-
|
|
509
|
-
|
|
510
|
-
|
|
511
|
-
|
|
512
|
-
# Tell the CLI to use your dev plist (`DEV-Info.plist`).
|
|
513
|
-
# Note that the hyphen separator can be explicitly stated.
|
|
514
|
-
code-push-standalone release-react MyApp-iOS ios --pre "DEV-"
|
|
293
|
+
appcenter codepush deployment list -k -a johndoe/rn2_android
|
|
294
|
+
revopush deployment add rn2_android appcenter_Staging -k <Staging_Key>
|
|
295
|
+
revopush deployment add rn2_android appcenter_Production -k <Production_Key>
|
|
515
296
|
```
|
|
516
297
|
|
|
517
|
-
|
|
518
|
-
|
|
519
|
-
#### Sourcemap output parameter
|
|
520
|
-
|
|
521
|
-
This specifies the relative path to where the generated JS bundle's sourcemap file should be written. If left unspecified, sourcemaps will not be generated.
|
|
522
|
-
|
|
523
|
-
_NOTE: This parameter can be set using either --sourcemapOutput or -s_
|
|
524
|
-
|
|
525
|
-
#### Output directory parameter
|
|
526
|
-
|
|
527
|
-
This specifies the relative path to where the assets, JS bundle and sourcemap files should be written. If left unspecified, the assets, JS bundle and sourcemap will be copied to the `/tmp/CodePush` folder.
|
|
528
|
-
|
|
529
|
-
_NOTE: This parameter can be set using either --outputDir or -o_
|
|
530
|
-
|
|
531
|
-
#### Use Hermes parameter
|
|
532
|
-
|
|
533
|
-
This parameter enforces the use of the Hermes compiler. If not specified, the automatic checks will be performed, inspecting the `build.gradle` and `Podfile` for the Hermes flag.
|
|
534
|
-
|
|
535
|
-
_NOTE: This parameter can be set using either --hermesEnabled or -h_
|
|
298
|
+
Repeat for all other deployment you have in Appcenter and wish to continue to use in Revopush.
|
|
536
299
|
|
|
537
|
-
|
|
300
|
+
## 4. Setting Up Revopush from Scratch
|
|
538
301
|
|
|
539
|
-
|
|
302
|
+
If you're new to Revopush and want to set up OTA updates for your app, follow these steps.
|
|
540
303
|
|
|
541
|
-
|
|
542
|
-
|
|
543
|
-
#### Extra hermes flags parameter
|
|
544
|
-
|
|
545
|
-
Hermes flags which will be passed to Hermes compiler.
|
|
546
|
-
|
|
547
|
-
_NOTE: This parameter can be set using either --extraHermesFlags or -hf_
|
|
548
|
-
|
|
549
|
-
#### Private key path parameter
|
|
550
|
-
|
|
551
|
-
Private key path which is used for code signing.
|
|
552
|
-
|
|
553
|
-
_NOTE: This parameter can be set using either --privateKeyPath or -k_
|
|
554
|
-
|
|
555
|
-
#### Xcode project file parameter
|
|
556
|
-
|
|
557
|
-
Path to the Xcode project or project.pbxproj file.
|
|
558
|
-
|
|
559
|
-
_NOTE: This parameter can be set using either --xcodeProjectFile or -xp_
|
|
560
|
-
|
|
561
|
-
#### Xcode target name parameter
|
|
562
|
-
|
|
563
|
-
Name of target (PBXNativeTarget) which specifies the binary version you want to target this release at (iOS only).
|
|
564
|
-
|
|
565
|
-
_NOTE: This parameter can be set using either --xcodeTargetName or -xt_
|
|
566
|
-
|
|
567
|
-
#### Build configuration name parameter
|
|
568
|
-
|
|
569
|
-
Name of build configuration which specifies the binary version you want to target this release at. For example, 'Debug' or 'Release' (iOS only).
|
|
570
|
-
|
|
571
|
-
_NOTE: This parameter can be set using either --buildConfigurationName or -c_
|
|
572
|
-
|
|
573
|
-
## Debugging CodePush Integration
|
|
574
|
-
|
|
575
|
-
Once you've released an update, React Native plugin has been integrated into your app, it can be helpful to diagnose how the plugin is behaving, especially if you run into an issue and want to understand why. In order to debug the CodePush update discovery experience, you can run the following command in order to easily view the diagnostic logs produced by the CodePush plugin within your app:
|
|
304
|
+
### 4.1 Logging In
|
|
576
305
|
|
|
577
306
|
```shell
|
|
578
|
-
|
|
579
|
-
|
|
580
|
-
# View all CodePush logs from a running
|
|
581
|
-
# instace of the iOS simulator.
|
|
582
|
-
code-push-standalone debug ios
|
|
583
|
-
|
|
584
|
-
# View all CodePush logs from a running
|
|
585
|
-
# Android emulator or attached device.
|
|
586
|
-
code-push-standalone debug android
|
|
307
|
+
revopush login
|
|
587
308
|
```
|
|
588
309
|
|
|
589
|
-
|
|
590
|
-
|
|
591
|
-
Under the covers, this command simply automates the usage of the iOS system logs and ADB logcat, but provides a platform-agnostic, filtered view of all logs coming from the CodePush plugin. This way, you don't need to learn and/or use another tool simply to be able to answer basic questions about how CodePush is behaving.
|
|
592
|
-
|
|
593
|
-
_NOTE: The debug command supports both emulators and devices for Android, but currently only supports listening to logs from the iOS simulator. We hope to add device support soon._
|
|
310
|
+
### 4.2 Creating Applications
|
|
594
311
|
|
|
595
|
-
|
|
596
|
-
|
|
597
|
-
After releasing an update, there may be scenarios where you need to modify one or more of the metadata attributes associated with it (e.g. you forgot to mark a critical bug fix as mandatory, you want to increase the rollout percentage of an update). You can easily do this by running the following command:
|
|
312
|
+
#### For iOS
|
|
598
313
|
|
|
599
314
|
```shell
|
|
600
|
-
|
|
601
|
-
[--label <releaseLabel>]
|
|
602
|
-
[--mandatory <isMandatory>]
|
|
603
|
-
[--description <description>]
|
|
604
|
-
[--rollout <rolloutPercentage>]
|
|
605
|
-
[--disabled <isDisabled>]
|
|
606
|
-
[--targetBinaryVersion <targetBinaryVersion>]
|
|
315
|
+
revopush app add myAmazingApp_ios
|
|
607
316
|
```
|
|
608
317
|
|
|
609
|
-
|
|
610
|
-
|
|
611
|
-
Aside from the `appName` and `deploymentName`, all parameters are optional, and therefore, you can use this command to update just a single attribute or all of them at once. Calling the `patch` command without specifying any attribute flag will result in a no-op.
|
|
318
|
+
#### For Android:
|
|
612
319
|
|
|
613
320
|
```shell
|
|
614
|
-
|
|
615
|
-
code-push-standalone patch MyApp-iOS Production -m
|
|
616
|
-
|
|
617
|
-
# Increase the rollout for v23 to 50%
|
|
618
|
-
code-push-standalone patch MyApp-iOS Production -l v23 -rollout 50%
|
|
321
|
+
revopush app add myAmazingApp_android
|
|
619
322
|
```
|
|
620
323
|
|
|
621
|
-
|
|
622
|
-
|
|
623
|
-
Indicates which release (e.g. `v23`) you want to update within the specified deployment. If ommitted, the requested changes will be applied to the latest release in the specified deployment. In order to look up the label for the release you want to update, you can run the `code-push-standalone deployment history` command and refer to the `Label` column.
|
|
624
|
-
|
|
625
|
-
_NOTE: This parameter can be set using either `--label` or `-l`_
|
|
626
|
-
|
|
627
|
-
### Mandatory parameter
|
|
628
|
-
|
|
629
|
-
This is the same parameter as the one described in the [above section](#mandatory-parameter), and simply allows you to update whether the release should be considered mandatory or not. Note that `--mandatory` and `--mandatory true` are equivalent, but the absence of this flag is not equivalent to `--mandatory false`. Therefore, if the parameter is ommitted, no change will be made to the value of the target release's mandatory property. You need to set this to `--mandatory false` to explicitly make a release optional.
|
|
324
|
+
This will create your app along with default Staging and Production deployments.
|
|
630
325
|
|
|
631
|
-
###
|
|
326
|
+
### 4.3 Creating Deployments
|
|
632
327
|
|
|
633
|
-
|
|
634
|
-
|
|
635
|
-
### Disabled parameter
|
|
636
|
-
|
|
637
|
-
This is the same parameter as the one described in the [above section](#disabled-parameter), and simply allows you to update whether the release should be disabled or not. Note that `--disabled` and `--disabled true` are equivalent, but the absence of this flag is not equivalent to `--disabled false`. Therefore, if the parameter is ommitted, no change will be made to the value of the target release's disabled property. You need to set this to `--disabled false` to explicitly make a release acquirable if it was previously disabled.
|
|
638
|
-
|
|
639
|
-
### Rollout parameter
|
|
640
|
-
|
|
641
|
-
This is the same parameter as the one described in the [above section](#rollout-parameter), and simply allows you to increase the rollout percentage of the target release. This parameter can only be set to an integer whose value is greater than the current rollout value. Additionally, if you want to "complete" the rollout, and therefore, make the release available to everyone, you can simply set this parameter to `--rollout 100`. If this parameter is ommitted, no change will be made to the value of the target release's rollout parameter.
|
|
642
|
-
|
|
643
|
-
Additionally, as mentioned above, when you release an update without a rollout value, it is treated equivalently to setting the rollout to `100`. Therefore, if you released an update without a rollout, you cannot change the rollout property of it via the `patch` command since that would be considered lowering the rollout percentage.
|
|
644
|
-
|
|
645
|
-
### Target binary version parameter
|
|
646
|
-
|
|
647
|
-
This is the same parameter as the one described in the [above section](#target-binary-version-parameter), and simply allows you to update the semver range that indicates which binary version(s) a release is compatible with. This can be useful if you made a mistake when originally releasing an update (e.g. you specified `1.0.0` but meant `1.1.0`) or you want to increase or decrease the version range that a release supports (e.g. you discovered that a release doesn't work with `1.1.2` after all). If this parameter is ommitted, no change will be made to the value of the target release's version property.
|
|
328
|
+
If you need more deployments (e.g., Development, Testing), use:
|
|
648
329
|
|
|
649
330
|
```shell
|
|
650
|
-
|
|
651
|
-
# by scoping its eligibility to users running >= 1.0.5
|
|
652
|
-
code-push-standalone patch MyApp-iOS Staging -t "1.0.0 - 1.0.5"
|
|
331
|
+
revopush deployment add myAmazingApp_android Development
|
|
653
332
|
```
|
|
654
333
|
|
|
655
|
-
|
|
334
|
+
List All Deployments:
|
|
656
335
|
|
|
657
|
-
|
|
658
|
-
|
|
659
|
-
```
|
|
660
|
-
code-push-standalone promote <appName> <sourceDeploymentName> <destDeploymentName>
|
|
661
|
-
[--description <description>]
|
|
662
|
-
[--label <label>]
|
|
663
|
-
[--disabled <disabled>]
|
|
664
|
-
[--mandatory]
|
|
665
|
-
[--noDuplicateReleaseError]
|
|
666
|
-
[--rollout <rolloutPercentage>]
|
|
667
|
-
[--targetBinaryVersion <targetBinaryVersion]
|
|
336
|
+
```shell
|
|
337
|
+
revopush deployment ls myAmazingApp_android -k
|
|
668
338
|
```
|
|
669
339
|
|
|
670
|
-
|
|
671
|
-
|
|
672
|
-
1. It's quicker, since you don't need to reassemble the release assets you want to publish or remember the description/app store version that are associated with the source deployment's release.
|
|
340
|
+
## 5. Updating Your React Native App
|
|
673
341
|
|
|
674
|
-
|
|
342
|
+
After setting up Revopush, update your React Native application to point to the Revopush server.
|
|
675
343
|
|
|
676
|
-
|
|
344
|
+
### 5.1 iOS Configuration
|
|
677
345
|
|
|
678
|
-
|
|
346
|
+
1. **Open `Info.plist`:** Add the following entries:
|
|
679
347
|
|
|
680
|
-
|
|
348
|
+
```xml
|
|
349
|
+
<key>CodePushDeploymentKey</key>
|
|
350
|
+
<string>Your_Deployment_Key</string>
|
|
351
|
+
<key>CodePushServerURL</key>
|
|
352
|
+
<string>https://api.revopush.org</string>
|
|
353
|
+
```
|
|
681
354
|
|
|
682
|
-
|
|
355
|
+
An example for `myAmazingApp_ios` app and `Staging` deployment:
|
|
683
356
|
|
|
684
|
-
|
|
357
|
+
```xml
|
|
358
|
+
<key>CodePushDeploymentKey</key>
|
|
359
|
+
<string>vUOFPtZfOlhXHPEDE3nkf7nP6lJ4VJHvdy5W-g</string>
|
|
360
|
+
<key>CodePushServerURL</key>
|
|
361
|
+
<string>https://api.revopush.org</string>
|
|
362
|
+
```
|
|
685
363
|
|
|
686
|
-
|
|
364
|
+
2. **Dynamic Deployment Key (Optional):** To switch deployments dynamically in your JavaScript code, use [Code-Push options](https://github.com/microsoft/react-native-code-push/blob/master/docs/api-js.md#CodePushOptions)
|
|
687
365
|
|
|
688
|
-
|
|
366
|
+
### 5.2 Android Configuration
|
|
689
367
|
|
|
690
|
-
|
|
368
|
+
1. Open `strings.xml`: Add the following entries:
|
|
691
369
|
|
|
692
|
-
|
|
370
|
+
```xml
|
|
371
|
+
<string moduleConfig="true" name="CodePushDeploymentKey">Your_Deployment_Key</string>
|
|
372
|
+
<string moduleConfig="true" name="CodePushServerUrl">https://api.revopush.org</string>
|
|
373
|
+
```
|
|
693
374
|
|
|
694
|
-
|
|
375
|
+
An example `myAmazingApp_android` app and `Staging` deployment `strings.xml`:
|
|
695
376
|
|
|
696
|
-
|
|
377
|
+
```xml
|
|
378
|
+
<string moduleConfig="true" name="CodePushDeploymentKey">kbAXqSrgEfLPcuvU3Fe0SCqX5HpOVJHvdy5W-g</string>
|
|
379
|
+
<string moduleConfig="true" name="CodePushServerUrl">https://api.revopush.org</string>
|
|
380
|
+
```
|
|
697
381
|
|
|
698
|
-
|
|
382
|
+
2. **Dynamic Deployment Key (Optional):** To switch deployments dynamically in your JavaScript code, use [Code-Push options](https://github.com/microsoft/react-native-code-push/blob/master/docs/api-js.md#CodePushOptions)
|
|
699
383
|
|
|
700
|
-
|
|
384
|
+
## 6. Releasing Updates
|
|
701
385
|
|
|
702
|
-
|
|
386
|
+
Once your app is configured, you can release updates to your users.
|
|
703
387
|
|
|
704
|
-
|
|
388
|
+
### 6.1 For iOS
|
|
705
389
|
|
|
706
390
|
```shell
|
|
707
|
-
|
|
708
|
-
# available to all versions using that deployment
|
|
709
|
-
code-push-standalone promote MyApp-iOS Staging Production -t "*"
|
|
391
|
+
revopush release-react rn2_ios ios -d Staging
|
|
710
392
|
```
|
|
711
393
|
|
|
712
|
-
|
|
394
|
+
**What Happens:**
|
|
395
|
+
- Bundles your JavaScript code.
|
|
396
|
+
- Uploads the bundle and assets to Revopush.
|
|
397
|
+
- Releases the update to the Staging deployment of rn2_ios.
|
|
713
398
|
|
|
714
|
-
|
|
399
|
+
**Success Message:**
|
|
715
400
|
|
|
401
|
+
```shell
|
|
402
|
+
...
|
|
403
|
+
Successfully released an update containing the "/var/folders/my/lwrczz7503g5911_wf51jsvm0000gp/T/CodePush" directory to the "Staging" deployment of the "rn2_ios" app.
|
|
716
404
|
```
|
|
717
|
-
code-push-standalone rollback <appName> <deploymentName>
|
|
718
|
-
code-push-standalone rollback MyApp-iOS Production
|
|
719
|
-
```
|
|
720
|
-
|
|
721
|
-
This has the effect of creating a new release for the deployment that includes the **exact same code and metadata** as the version prior to the latest one. For example, imagine that you released the following updates to your app:
|
|
722
405
|
|
|
723
|
-
|
|
724
|
-
| ------- | ----------------- | --------- |
|
|
725
|
-
| v1 | Initial release! | Yes |
|
|
726
|
-
| v2 | Added new feature | No |
|
|
727
|
-
| v3 | Bug fixes | Yes |
|
|
406
|
+
### 6.2 For Android
|
|
728
407
|
|
|
729
|
-
|
|
408
|
+
```shell
|
|
409
|
+
revopush release-react rn2_android android -d appcenter-Staging
|
|
410
|
+
```
|
|
730
411
|
|
|
731
|
-
|
|
732
|
-
| --------------------------- | ----------------- | --------- |
|
|
733
|
-
| v1 | Initial release! | Yes |
|
|
734
|
-
| v2 | Added new feature | No |
|
|
735
|
-
| v3 | Bug fixes | Yes |
|
|
736
|
-
| v4 (Rollback from v3 to v2) | Added new feature | No |
|
|
412
|
+
**What Happens:**
|
|
737
413
|
|
|
738
|
-
|
|
414
|
+
- Bundles your JavaScript code.
|
|
415
|
+
- Uploads the bundle and assets to Revopush.
|
|
416
|
+
- Releases the update to the appcenter-Staging deployment of rn2_android.
|
|
739
417
|
|
|
740
|
-
|
|
418
|
+
**Success Message:**
|
|
741
419
|
|
|
420
|
+
```shell
|
|
421
|
+
...
|
|
422
|
+
Successfully released an update containing the "/var/folders/my/lwrczz7503g5911_wf51jsvm0000gp/T/CodePush" directory to the "appcenter-Staging" deployment of the "rn2_android" app.
|
|
742
423
|
```
|
|
743
|
-
code-push-standalone rollback MyApp-iOS Production --targetRelease v34
|
|
744
|
-
```
|
|
745
|
-
|
|
746
|
-
_NOTE: The release produced by a rollback will be annotated in the output of the `deployment history` command to help identify them more easily._
|
|
747
424
|
|
|
748
|
-
|
|
425
|
+
### 6.3 Additional Options
|
|
749
426
|
|
|
750
|
-
|
|
427
|
+
For more customization, view all options:
|
|
751
428
|
|
|
752
|
-
```
|
|
753
|
-
|
|
429
|
+
```shell
|
|
430
|
+
revopush release-react -h
|
|
754
431
|
```
|
|
755
432
|
|
|
756
|
-
|
|
433
|
+
## 7. Summary and Resources
|
|
757
434
|
|
|
758
|
-
|
|
759
435
|
|
|
760
|
-
|
|
436
|
+
Migrating your OTA updates from Appcenter to Revopush is straightforward with our CLI tools.
|
|
437
|
+
Whether you're migrating existing applications or setting up new ones,
|
|
438
|
+
Revopush offers a seamless experience with familiar commands and robust features.
|
|
761
439
|
|
|
762
|
-
By default, the history doesn't display the author of each release, but if you are collaborating on an app with other developers, and want to view who released each update, you can pass the additional `--displayAuthor` (or `-a`) flag to the history command.
|
|
763
440
|
|
|
764
|
-
|
|
441
|
+
**Quick Command Reference:**
|
|
765
442
|
|
|
766
|
-
|
|
443
|
+
| Appcenter | Revopush | Comment |
|
|
444
|
+
|:---------------------------------|:------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------:|
|
|
445
|
+
| `appcenter login` | `revopush login` | Log in |
|
|
446
|
+
| `appcenter codepush deployment` | `revopush deployment` | View and manage your app deployments |
|
|
447
|
+
| `appcenter apps` | `revopush app` | View and manage your apps |
|
|
448
|
+
| `appcenter codepush patch` | `revopush patch` | Update the metadata for an existing CodePush release |
|
|
449
|
+
| `appcenter codepush promote` | `revopush promote` | Create a new release for the destination deployment, which includes the exact code and metadata from the latest release of the source deployment |
|
|
450
|
+
| `appcenter codepush release-react`| `revopush release-react` | Release a React Native update to an app deployment |
|
|
451
|
+
| `appcenter codepush rollback` | `revopush rollback` | Rollback a deployment to a previous release |
|
|
452
|
+
| `appcenter logout` | `revopush logout` | Log out |
|
|
767
453
|
|
|
768
|
-
|
|
454
|
+
### **Helpful Resources:**
|
|
455
|
+
- React Native CodePush [GitHub](https://github.com/microsoft/react-native-code-push)
|
|
456
|
+
- React Native Client SDK [docs](https://learn.microsoft.com/en-us/appcenter/distribution/codepush/rn-overview)
|
|
457
|
+
- Best practices for [Multi-Deployment Testing](https://learn.microsoft.com/en-us/appcenter/distribution/codepush/rn-deployment)
|
|
769
458
|
|
|
770
|
-
|
|
771
|
-
|
|
772
|
-
```
|
|
459
|
+
**Need More Help?**
|
|
460
|
+
Contact our support team at [support@revopush.org](mailto:support@revopush.org) or visit our [website](https://revopush.org).
|
|
773
461
|
|
|
774
|
-
After running this command, client devices configured to receive updates using its associated deployment key will no longer receive the updates that have been cleared. This command is irreversible, and therefore should not be used in a production deployment.
|