$3f
Ce skill est le chef d'orchestre des 3 skills spécialisés (deploy-eas, deploy-app-store, deploy-play-store dans atum-workflows). Il fournit le workflow complet d'une release mobile en production, pas les détails techniques des outils.
À lire avant de commencer : ce skill + les 3 skills de atum-workflows ci-dessus.
┌─────────────────────────────────────────────────────────────┐
│ 1. DEV │
│ git push → CI → EAS Build dev profile → TestFlight internal │
│ Play Console internal │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ 2. STAGING │
│ PR merge main → EAS Build preview → TestFlight external │
│ Play Closed Testing │
│ Beta testers (50-500) │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ 3. PRODUCTION │
│ Git tag vX.Y.Z → EAS Build production → EAS Submit │
│ App Store Review (1-2d) │
│ Play Store Review (1-3d) │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ 4. ROLLOUT │
│ iOS phased release 7 days (1→2→5→10→20→50→100%) │
│ Play Console staged rollout 10%→50%→100% │
│ Monitor crashes via Crashlytics / Sentry │
└─────────────────────────────────────────────────────────────┘
1.0.0 — Major (breaking UI change)1.1.0 — Minor (new feature)1.0.1 — Patch (bug fix)Auto-incrémenté par EAS (autoIncrement: true dans eas.json) ou via cli.appVersionSource: "remote".
Règle Apple : build number strictement croissant pour chaque upload (même si même version marketing).
Règle Play : versionCode strictement croissant, versionName libre.
Garder la même version marketing sur les deux stores. Incrémenter au même moment.
// app.json (Expo)
{
"expo": {
"version": "1.2.0",
"ios": {
"buildNumber": "1.2.0"
},
"android": {
"versionCode": 42
}
}
}
main ─────●────────────●─────────────●──── (production releases)
│ │ │
release/1.2.0 │ ●─────●───┤ │
│ │ │ │ │
develop ──●──┴──●──●──●───●───●─────●───●──── (integration)
│ │ │
feature/x ●────● │ │
│ │
hotfix/y ●─────● (critical bug fixes)
develop — intégration continue, déclenche TestFlight internal + Play Internalrelease/X.Y.Z — freeze + QA beta, déclenche TestFlight external + Play Closed Testingmain — production uniquement, tag vX.Y.Z déclenche EAS Submithotfix/Y — urgent fix, branché depuis main, merge dans main + developPour les équipes de 1-3 devs : juste main + feature branches. Les tags vX.Y.Z déclenchent les submissions.
Avant d'envoyer le build en review — commun iOS + Android :
version + buildNumber / versionCoderelease/1.2.0 dans main via PRv1.2.0 sur maineas build --profile production --platform alleas submit --profile production --platform ios --latest → upload App Store Connecteas submit --profile production --platform android --latest → upload Play ConsolePour un bug critique (crash, data loss, security) :
hotfix/1.2.1 depuis mainSi le fix est 100 % JavaScript (pas de natif modifié) :
eas update --branch production --message "Fix login crash"
Les users reçoivent la update au prochain lancement. Pas de review Apple. Bypass du review uniquement pour des fixes JS, et dans les limites des guidelines (4.1 Copycats, 3.2.2 Acceptable business model, etc.).
Si bug détecté pendant le rollout :
Recommandation agency : Release train pour les clients, Ship when ready pour les projets internes.
Au lieu de releaser un feature à 100 % des users au même moment :
// Via PostHog, LaunchDarkly, Statsig, ou un simple JSON remote
const enableNewCheckout = useFeatureFlag('new-checkout')
return enableNewCheckout ? <NewCheckout /> : <OldCheckout />
deploy-eas (dans atum-workflows)deploy-app-store (dans atum-workflows)deploy-play-store (dans atum-workflows)expo-expert (dans atum-stack-mobile)swift-expert (dans atum-stack-mobile)kotlin-expert (dans atum-stack-mobile)flutter-dart-expert (dans atum-stack-mobile)security-reviewer