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

Abierto
  • ¿Algo no está bien?
#513 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
15/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
github-actions, nodejs, react-native
Área
build-system, ci-cd, mobile, release

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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
Lenguaje dominante
TypeScript
Estrellas
3
Forks
2
Merge medio
18 min
PR fusionados (30 d)
118

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de code4romania/vic

Todos los issues de code4romania/vic

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.