Engineer App

Appearance

Production Release Checklist ​

There are two types of releases: store releases and OTA releases. For emergency bug fixes, use OTA Updates which don't require store review.

A store release is required when:

  • Native code changes - Updates to iOS or Android components
  • New features - Significant new functionality
  • Config changes - Any change to Doppler config will cause OTAs to no longer work, requiring an immediate store release

Follow Up Critical OTAs with a Store Release

OTA updates are lost when the app is reinstalled. If an OTA contains a critical fix, a store release should follow to ensure the fix persists for users who reinstall (which is common, as it's the typical advice given by ops to users with issues).

Store release ​

For more info on how the store release GitHub Action works, see Store Releases.

1. QA Sign-Off ​

  • [ ] QA team has tested and approved develop or feature branch for release
  • [ ] All critical bugs resolved
  • [ ] Regression testing completed
  • [ ] E2E tests passing
  • [ ] Jira release completed

2. Version Bump and Tagging (on main) ​

  • [ ] Merge into main and checkout main branch
  • [ ] Version number bumped in package.json and app.config.ts
  • [ ] Commit created with version bump 🏷️ v1.2.3
  • [ ] Git tag created: git tag 1.2.3
  • [ ] Tag pushed: git push origin 1.2.3

3. Automated Builds ​

  • [ ] GitHub workflows triggered automatically
  • [ ] Production builds created successfully (iOS & Android)
  • [ ] Production E2E builds created successfully

4. E2E Testing on Production Builds ​

  • [ ] QA runs E2E tests on production-e2e builds (you'll need to ask them in Slack)
  • [ ] All E2E tests passing
  • [ ] No critical issues found

5. App Store Preparation ​

  • [ ] Release notes written (by Emily) and reviewed
  • [ ] App store metadata updated if needed
  • [ ] Screenshots updated if UI changed
  • [ ] Privacy policy reviewed if permissions changed
  • [ ] Discussion about immediate / gradual release schedule

6. Store Submission ​

  • [ ] iOS app submitted to App Store Connect
  • [ ] Android app submitted to Google Play Console
  • [ ] Submission approved
  • [ ] Release

Review Timeline

  • iOS: Reviews typically take 24-48 hours
  • Android: Reviews typically take a few hours to 1 day

7. Post-Release Comms ​

  • [ ] Post a message in #engineer-app Slack channel:
🚀 Engineer app <version> has been released 🚀
<Jira release link>
<What's New text from the stores>
Summary:
- <non-technical bullet points for ops>

8. Post-Release Monitoring ​

  • [ ] Monitor Sentry for crash reports and errors
  • [ ] Track adoption rate and rollout progress

OTA release ​

Production OTAs push urgent fixes directly to users without requiring store review.

For more info on how the OTA GitHub Action works, see OTA Updates.

1. Pre-Release Verification ​

  • [ ] Fix has been tested on develop or feature branch
  • [ ] No native code changes included
  • [ ] No Doppler config changes since last store release
  • [ ] QA has approved the fix for production

2. Prepare Release ​

  • [ ] Merge the branch into main
  • [ ] Checkout main branch
  • [ ] Git tag created: git tag 1.2.3-1 (the -N suffix indicates an OTA)
  • [ ] Tag pushed: git push origin 1.2.3-1

WARNING

Do not bump the version number in the code - this will change the runtime fingerprint and the OTA will not apply to the latest store release.

3. Deploy ​

  • [ ] Observe the production OTA workflow in GitHub Actions triggered by the tag push
  • [ ] Verify update completes successfully
  • [ ] Confirm update is visible in EAS dashboard

4. Post-Release Comms ​

  • [ ] Post a message in #engineer-app Slack channel:
🔄 Engineer app OTA update released 🔄
<Jira ticket link>
Summary:
- <brief description of the fix>

5. Post-Release Verification ​

  • [ ] Monitor Sentry for any new errors

Plan a Follow-Up Store Release

Schedule a store release soon to ensure the fix persists for users who reinstall the app.