[Mobile] Automated builds to TestFlight / Play internal testing and scripted releases

Aperta
  • Qualcosa non va?
#513 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
15/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
github-actions, nodejs, react-native
Ambito
build-system, ci-cd, mobile, release

Direzione di ricerca

Start with mobile/eas.json, mobile/app.config.ts and the scripts block in mobile/package.json, then read where mobile/scripts/build.js and mobile/scripts/release.js would fit. The work depends on store credentials that a newcomer will not have, so begin with the dry-run and safety-gate logic that can be checked without them. Done means npm run build and npm run release --dry-run run with no store writes, and a production artifact that contains the staging API host is rejected.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

agent-ready devops enhancement :rocket: mobile-app vic-2.0

Context

Set up the same build and release flow we use on our other Expo apps, so a build goes to testers without manual steps and a release is one command.

Scope

  • npm run build (mobile/scripts/build.js): pick a preset (env + platform), bump version / build numbers, build with EAS, upload the result:
    • Android .aab to Google Play internal testing (track internal, status completed);
    • iOS .ipa to TestFlight.
    • Presets for android-production-upload, ios-production-upload, both-production-upload and a preview APK for direct install.
    • Artifacts named vic-<version>-<platform><build>-<profile>.<ipa|aab|apk>, with a git tag v<version>-<platform><build> per uploaded build.
  • npm run release (mobile/scripts/release.js): promote an already uploaded production build to the Play production track (staged rollout 20 / 50 / 100 %) and submit the App Store version for review, with release notes drafted from the commits since the previous build tag. --dry-run prints every store write; --watch polls both stores until the release is live.
    • Safety gates before any store write: only production profile artifacts, the JS bundle must contain the production API host and must not contain the staging one, the store must already know the build, and an explicit confirmation phrase.
  • npm run update -- <channel> "<message>": EAS Update (OTA) to the development, staging and production channels.
  • Optional: a GitHub Actions workflow that runs the build + upload on a tag / manual dispatch, using the same scripts and the secrets below.
  • Clean up mobile/eas.json: fill submit.production (iOS ascAppId, Android track internal) and drop the Cognito env vars once own auth ships.

Keys and access to configure

Accounts are owned by Commit Global; Tribus needs the access below. Local files go in mobile/_serviceKeys/ (gitignored); in CI they become repository secrets.

Apple

  • App Store Connect API key (.p8) with App Manager role or above, plus its Key ID and Issuer ID. With it, EAS also manages the distribution certificate and provisioning profile without an Apple login.
  • Apple Team ID of the Commit Global developer account.
  • The app's Apple ID in App Store Connect (ascAppId in eas.json).
  • TestFlight internal testers group (Tribus + Commit Global).

Google

  • Google Cloud service account JSON key, invited in Play Console → Users and permissions with release rights on the VIC app.
  • Play Console: the first .aab must already be uploaded by hand (it is, for the current app); internal testing track with the tester list.
  • google-services.json (Firebase) for Android push, if push stays on Firebase.

Expo / other

  • EXPO_TOKEN (robot token) for the Commit Global Expo account / VIC project, for CI builds and EAS Update.
  • SENTRY_AUTH_TOKEN, if we upload source maps and dSYMs to Sentry.
  • stores.json in _serviceKeys/: { "ascKeyId": "…", "ascIssuerId": "…", "appleTeamId": "…" }.

Acceptance criteria

  • npm run build in mobile/ builds with EAS and uploads Android to Play internal testing and iOS to TestFlight, without manual steps once keys are in _serviceKeys/.
  • npm run release promotes an uploaded production build (Play staged rollout, App Store review) and --dry-run performs no store writes.
  • A production artifact containing the staging API host is rejected before any store write.
  • mobile/scripts/README.md documents commands and the one-time key setup.
  • No secret is committed; _serviceKeys/ and artifacts are gitignored.

Dependencies

Phase 0. No blockers.

Where to look

  • mobile/eas.json
  • mobile/app.config.ts
  • mobile/package.json
Lingua principale
TypeScript
Stelle
3
Fork
2
Merge medio
18m
PR unite (30g)
118

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di code4romania/vic

Tutte le issue di code4romania/vic

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.