-
Notifications
You must be signed in to change notification settings - Fork 0
Development: CodePush
Rebecka Z edited this page Apr 20, 2018
·
1 revision
Codepush is Hippware's quick way to verify fixes without officially pushing them into builds. Codepush expedites the development cycle because issues don't need to wait for builds. Codepush can also be used for beta testing as well as A|B testing. Codepush is only implemented via tinyrobot Staging App via by long pressing on the Version Number.
- Only javascript changes can be codepushed.
- Only isolated issues can be codepushed
- Other issues that can potentially affect a whole build will have to wait for a build deploy
- When isolated issues are code pushed they must sit in "In Progress" with Codepush Deploy label
- If an open ended issue begins to have multiple solutions via Codepush, the ticket needs to be broken down by the devs
- Devs needs to ensure the Codepush change is being tracked by commenting on the ticket for what was specifically codepushed and what date the Codepush was made
- When multiple devs working on the same issue create multiple codepushes, QA will only test the respective Codepushes in isolation (because it is impossible to do otherwise)
- The default Codepush = base version + anything in "In Progress, In Code Review, Waiting for Deploy" + the specific PR/issue being addressed with the push
- There may be times when we need to isolate functionality further in which case we could do base version + specific issue (and state as much in the Codepush description and the Github issue)
- Codepush solved tickets sitting in "Waiting for Deploy" are assumed to have been approved by Beng via the "In Code Review" column
- If a Codepush is an aggregate build of a previous Codepush, the dev needs to deploy the Codepush via the Staging-beta channel.
- If a Codepush is pushed in a Staging-dev Channel, QA will assume it is NOT an aggregate build.
- Codepush only works post onboarding flow, therefore onboarding issues cannot be tested via codepush, and only by builds
- If QA approves a Codepush deploy by verbally stating on the ticket "Codepush [date] verified", the Codepush can move to "In Code Review"
- QA will only test the isolated issue and will not fully test the Codepush release
- If the Codepush has a bug, QA will comment on the ticket below the Dev's Codepush comments on what specific bugs that Codepush has
- Updating to a Staging channel does not remove the Codepush, in order to remove the Codepush, QA will have to delete the app and reinstall without updating for any Codepushes in orer to be at a "build base level"
IMPORTANT: Because Codepush allows us to test and move quickly, it is essential to minimize confusion, therefore, all Codepush releases need to be commented and labeled for the ticket it is solving for by the dev. If a Codepush release does not have a ticket, the dev needs to create a ticket for it.
CodePush is a cloud service that enables React Native developers to deploy app updates directly to users’ devices. It bypasses some of the friction experienced with more traditional deployment services (e.g. Test Flight). It's a bit of a paradigm shift so this wiki is intended to answer some questions around how we might implement CodePush to speed up the dev -> QA flow on tinyrobot.
- much faster deployments to user devices (2-3 minutes)
- Rollbacks. If for some reason a CodePushed update doesn't work it can easily be reverted by the user (with appropriate UI built in) or by the developer.
- No App Store review (i.e. no potential rejection)
- Partial rollouts Target deploys to a percentage of users. A/B testing potential.
- JS updates only. Changes to native modules will require a traditional deployment.
- No dashboard. Currently everything in CodePush is handled via command line. While the CLI is fine for devs, there isn't a nice web dashboard for viewing deploy history (although it's in the works).
- Version tracking. Since CodePush makes it easier to push updates to end users it also makes it easier to get mixed up on which version users are looking at.
- No SLA. Since CodePush is still technically a "preview" (read beta) product it probably should be treated as such. In my (limited) experience it works great and for pre-release tinyrobot updates it should be more than adequate, but for production deploys we might want to tread lightly.
- On Friday afternoon Pavel receives a message from Miranda (her morning) that one of his PRs requires a slight tweak. The tweak takes a few minutes, but the deploy takes hours and by the time Mindy receives it it's very late in the day for Pavel and the resolution will have to wait for Monday. With CodePush he could implement the change, push to Mindy, and resolve before beginning his weekend.
- Install JS and native dependences according to instructions
- Register app via CodePush CLI and set up deployments (defaults to Staging and Production)
- Build React component and wrap root component
- (Optional) build front-end UI to let users choose how/when to receive updates and provide options for rolling back.
- Discuss version tracking scheme with rest of team. It's important to separately track the binary version (deployed via Test Flight) and the JS version (deployed via CodePush). New Github issues should include both for maximum clarity.