App Distribution
Clearly outline business needs for the app distribution. Fill in technical bits later
Deployment Checklists
Section titled “Deployment Checklists”We will follow a bi-weekly (every sprint) release rhythm, to maintain customer expectations and stay organised. Follow these guidelines to make sure we don’t miss any critical steps.
To know if we need an app release, backend pull requests should be tagged with “App Breaking”, “App Compatibility” or “App Feature” depending on changes made.
Staging Deployment
Section titled “Staging Deployment”This allows us to start testing features on staging before the end of the sprint.
2 days before the end of a sprint, we deploy to staging:
- Ensure app feature branches for the sprint are approved and merged into @dev
- Merge app @dev branch with @staging
- Ensure related backend features are also deployed on staging
Has anything changed in the native bundle?
- Create staging build for iOS
- Create staging build for Android
- Submit iOS build for external testing distribution (TestFlight)
- Submit Android build for external testing distribution (Firebase)
Otherwise:
- Push a staging OTA update (will go to both iOS/Android channels)
- Check progress of the OTA update via the Expo dashboard
Production Deployment
Section titled “Production Deployment”After sprint has been completed, we deploy to production.
- Ensure app @staging branch is approved and merged into @main
- Ensure related backend features are also deployed on production
Has anything changed in the native bundle?
- Create production build for iOS
- Create production build for Android
- Submit iOS build to App Store for review
- Submit Android build to Google Play for review
Otherwise:
- Push a production OTA update (will go to both iOS/Android channels)
- Check progress of the OTA update via the Expo dashboard
Production Hotfix
Section titled “Production Hotfix”Shit hits the fan
- Ensure app @hotfix branch is approved and merged into @main
- Ensure related backend hotfixes are also deployed on production
If only making JS bundle changes:
- Submit iOS build OTA
- Submit Android build OTA
Otherwise:
- Create production build for iOS
- Create production build for Android
- Submit iOS build to App Store for review
- Submit Android build to Google Play for review
Common Issues
Section titled “Common Issues”Frontend & Backend Out of Sync
Section titled “Frontend & Backend Out of Sync”The main fix is making sure we follow a structured release cadence tied with the web portal and backend codebases.
Review Lag Time
Section titled “Review Lag Time”We can reduce lag-time between build submission and an update being available on the app by sending OTA updates.
Every time a native bundle change happens, should we deploy it asap to get the review out of the way?
Branch Management
Section titled “Branch Management”On the backend, we should tag relevant pull requests with the following:
- App Breaking: API change will break features on the existing production app (bump the minimum version)
- App Compatibility: API change may interfere with existing production app functionality (prompt users to update)
- App Feature: API change introduces new features that won’t affect the existing production app (prompt users to update)
For breaking changes to the app, we need to bump the minimum app version in the production database. For issues that might cause compatibility issues, we need to make sure that we do an app deployment when that PR is merged.
Backwards Compatibility
Section titled “Backwards Compatibility”When developing app features, keep in mind how the functionality may be extended in the future. Build in error states to handle obvious future changes, such as new field types that are unrecognised.
Those error states may say “This feature may not work as intended. Please update the app to the latest version”.
We can also configure Expo Updates to prompt the user to update the app when a new version becomes available.
Another test we could run during backend CI checks is to mock the app by making all the API calls. This would introduce some extra maintenance overheads when changes to the app’s API layer are made.
iOS & Android Out of Sync
Section titled “iOS & Android Out of Sync”If you deploy one, you must always deploy the other as well.
Only deploying to TestFlight, and leaving an old build on Firebase only serves to confuse the client and ourselves, especially when we don’t know who’s on what platform.
App Versioning
Section titled “App Versioning”Semver
OTA Updates
Section titled “OTA Updates”Automations and Monitoring
Section titled “Automations and Monitoring”We need a README badge for latest production version deployed, as well as the latest OTA ID (truncated). Set up notifications if these are out of sync.