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

未关闭
  • 哪里不对？
#513 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
15/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
github-actions, nodejs, react-native
领域
build-system, ci-cd, mobile, release

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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
主要语言
TypeScript
星标
3
派生
2
平均合并
18 分钟
30 天内合并 PR
118

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

code4romania/vic 的其他 Issue

查看 code4romania/vic 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。