Automatiser mes releases React Native depuis mon Smartphone

Je développais une petite appli React Native pour le fun, et ca depuis mon iPhone. Avec Codex dans l’appli ChatGPT, je pouvais piloter mon agent sur mon Mac et faire avancer le projet sans rester assis devant mon bureau.

Puis arrivait la release. Et là, retour à l’ancien workflow Fastlane : lancer le build en local, garder un œil dessus et attendre que tout parte correctement vers TestFlight. Fastlane faisait le travail, mais sans CI ni infrastructure autour, mon Mac restait le centre des opérations.

Pour une app personnelle, je n’avais aucune envie de monter une petite usine à releases. Je voulais quelque chose de simple, peu coûteux et surtout cohérent avec ma façon de développer.

La contrainte est devenue assez évidente : si je peux développer depuis mon téléphone, je dois aussi pouvoir livrer depuis mon téléphone. Et via une seule application : GitHub.

Le résultat tient en une ligne :

Préparer → review → merge → tag → build EAS → TestFlight → tester → soumettre à App Review

Il reste deux décisions humaines dans ce parcours. La première lance la release avec sa version et son changelog. La seconde autorise la soumission du build testé à App Review. Entre les deux, les workflows bossent tout seuls. Il faut bien que le YAML serve à quelque chose.

Premier feu vert : préparer ce qui va partir

Depuis l’appli GitHub, j’ouvre le workflow de préparation. Je saisis une version sémantique, les notes de release en français, puis je le lance. À ce stade, mon travail tient dans ces deux champs.

workflow_dispatch crée directement le formulaire dans l’appli GitHub. Pas besoin de développer une interface dédiée pour envoyer deux valeurs à un pipeline.

Avant de toucher aux fichiers, le workflow vérifie que la release part de main, que la version est valide et que le champ « What’s New » n’est pas vide. Il aligne ensuite la version de l’application, du package et des métadonnées Apple.

Il lance les mêmes contrôles que pour n’importe quelle contribution : formatage, lint, vérification des types et tests. Si tout passe, il crée une branche release/X.Y.Z, commit les changes puis ouvre une PR.

PR_BODY contient le résumé et les release notes préparés juste avant. Rien de magique ici : la release devient une branche, un commit et une PR.

Depuis mon téléphone, je peux relire le changelog et vérifier une dernière fois les changes avant de merge. La release est clairement visible et peut être review, plutôt que préparée par une suite de commandes lancées hors de GitHub.

La release PR regroupe la version, la branche et les notes à review avant de merge.

Le tag vient après la review, pas avant

J’aurais pu créer le tag dès le premier workflow. C’était plus court, mais ça retirait la garantie qui m’intéressait vraiment : vérifier une dernière fois ce que j’envoie.

Un second workflow attend donc la fermeture de la PR et ne continue que si elle a bien été merge. Il récupère son merge_commit_sha, puis crée le tag annoté dessus.

Le tag répond à une question très concrète : quel code a produit ce build ? Si quelque chose coince plus tard, je retrouve immédiatement le commit utilisé.

Le même workflow crée ensuite la GitHub Release. EAS détecte le tag vX.Y.Z et démarre le build iOS de production.

EAS sort le build de mon Mac

EAS c’est le service cloud d’Expo pour construire et distribuer des applications. Dans mon cas, son rôle est simple : GitHub pousse le tag, EAS le détecte et lance le build sur leur infra.

La configuration tient en deux jobs. Le premier construit l’application avec le profil iOS de production. Le second attend le résultat, récupère son identifiant et envoie ce même build vers TestFlight.

TestFlight n’arrête pas l’automatisation

Une fois le binaire dans TestFlight, la release est préparée. Je peux l’installer sur mon iPhone et la partager avec d’autres personnes, pas seulement des devs. Elles installent l’app normalement, la testent et me donnent leur ressenti.

Le même build est disponible dans TestFlight pour la vérification sur un vrai appareil.

Ça permet de vérifier ce qu’aucun test automatisé ne mesure vraiment : le feeling de l’application, ses transitions et son comportement sur un vrai appareil.

Ce test manuel ne marque pas la fin de l’automatisation. Le pipeline attend juste mon deuxième feu vert, comme il attendait au départ la version et les notes de release.

Quand le build me convient, j’ouvre un second workflow dans GitHub. Je renseigne la version et je confirme la soumission. ASC CLI prend ensuite le relais pour piloter App Store Connect : il valide les métadonnées, sélectionne le dernier build TestFlight valide pour cette version, puis l’envoie à App Review.

Après les tests, la soumission à App Review demande une confirmation explicite.

Le workflow prend le dernier build valide de la version demandée. Il lance d’abord la commande avec --dry-run, puis exécute la même soumission avec --confirm. ASC CLI s’occupe du reste.

Je n’ai donc pas supprimé l’humain du pipeline. Je limite juste son rôle et le temps qu’il y passe : annoncer la release, tester le résultat et autoriser sa soumission. Tout le reste se fait tout seul.

Intention humaine → préparation automatisée → test humain → soumission automatisée

Ce que je garderais sur une autre app

Mon implémentation couvre aujourd’hui iOS, TestFlight et App Review. Android et Google Play restent à ajouter, mais le modèle ne dépend pas vraiment d’Apple.

Les principes que je conserverais :

• Préparer dans GitHub. La version, les notes et les métadonnées sont relues avant la création du tag.
• Taguer le commit réellement validé. En cas de problème, le tag permet de retrouver immédiatement le code qui a produit le build.
• Un seul outil pour chaque opération. EAS construit et envoie le binaire. Côté Apple, asc gère les métadonnées et la soumission à App Review. Pour le Play Store ca se ferait avec gpc
• Prendre la décisions. Je donne le feu vert ; le workflow exécute la suite.

Ce modèle reste très intéressant en équipe. GitHub garde ce qui va partir, les validations effectuées et les décisions prises. La release n’existe plus seulement dans le terminal ou dans la mémoire de la personne qui la prépare.

Et voilà. Depuis mon iPhone, je peux donner une version et un changelog, review la préparation, tester le build puis autoriser son départ vers App Review. Pas besoin de sortir un terminal de ma poche.

Je peux terminer depuis mon téléphone le parcours que j’y ai commencé : développer une idée, préparer sa release, la tester, puis l’envoyer vers l’App Store. Et franchement, la DX est plutôt sympa.

Ca reste forcement à améliorer/peaufiné mais ca fonctionne bien, essayez le !

Vous pouvez voir tout au complet ici sur le repo : https://github.com/ErwannRousseau/guessit

Et si vous avez des idées, des remarques ou des pistes d’amélioration, laissez-les dans les commentaires juste en dessous.