Sauvegarde et restauration Expo : guide pratique pour protéger votre pipeline de build mobile

Introduction

La sauvegarde et la restauration Expo doivent vous faire passer d'un problème détecté à un résultat vérifié. Commencez par identifier la version installée, la topologie de déploiement, les prérequis et le composant exact inspecté. Ce guide est destiné aux développeurs, consultants DevOps et équipes techniques de start-up qui doivent protéger leur pipeline de build mobile.

Il relie la sauvegarde, la restauration, la reprise après sinistre, le retour en arrière et la validation à des commandes, des sorties attendues, des signaux d'échec et des décisions de récupération. L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés plutôt que des secrets, vérifier le résultat et documenter comment récupérer si l'état attendu n'est pas atteint.

Inventaire des versions et de l'environnement

Avant toute opération de sauvegarde ou de restauration, capturez l'état exact de votre environnement Expo. Cela évite les incompatibilités de versions et garantit que vous pouvez reproduire la configuration.

Comment vérifier votre version Expo et votre environnement

Exécutez cette commande en lecture seule pour afficher la version globale de la CLI Expo :

expo --version

Exemple de sortie attendue :

6.3.10

Pour les versions du SDK et des dépendances spécifiques au projet, inspectez package.json et app.json :

node -e "console.log(require('./package.json').dependencies.expo)"
node -e "console.log(require('./app.json').expo.sdkVersion)"

Exemple de résultat :

~50.0.0
50.0.0

Prérequis

• Node.js 18 LTS ou plus récent.
• CLI Expo installée globalement (npm install -g expo-cli) ou utilisez npx expo pour les commandes au niveau du projet.
• Dépôt Git avec un arbre de travail propre (git status --porcelain doit retourner vide).
• Accès à votre plateforme de contrôle de version (GitHub, GitLab, Bitbucket) et à tout système CI/CD.

Rayon d'impact

Les vérifications de version sont en lecture seule et n'ont aucun impact sur les services en cours d'exécution. Elles peuvent être exécutées à tout moment en toute sécurité.

Vérification

Confirmez que la version correspond à celle documentée dans le fichier de verrouillage de votre projet (yarn.lock ou package-lock.json) et sur votre exécuteur CI.

Chemin de configuration sûr

Suivez un chemin structuré lors de la modification des fichiers de configuration Expo tels que app.json, eas.json ou metro.config.js. Une simple faute de frappe peut casser votre build ou divulguer des secrets.

Étape 1 : Observer la configuration actuelle

Affichez le app.json actuel sans le modifier :

cat app.json

Cela montre les paramètres actuels. Notez toutes les variables d'environnement référencées avec process.env.

Étape 2 : Effectuer un changement ciblé avec une sauvegarde

Créez toujours une sauvegarde avant de modifier :

cp app.json app.json.bak.$(date +%Y%m%d%H%M%S)

Modifiez ensuite en utilisant une méthode sous contrôle de version. Par exemple, pour ajouter une variable d'environnement pour votre URL d'API dans eas.json :

{
  "build": {
    "production": {
      "env": {
        "API_URL": "https://api.example.com"
      }
    }
  }
}

Remplacez l'URL par un espace réservé dans la documentation ; ne committez jamais de vrais secrets.

Étape 3 : Vérifier le changement

Après modification, validez la syntaxe JSON :

node -e "JSON.parse(require('fs').readFileSync('app.json', 'utf8')); console.log('Valid JSON')"

Sortie attendue :

Valid JSON

Exécutez ensuite un essai de prebuild pour voir si la configuration se résout :

npx expo prebuild --no-install

Cela génère les projets natifs en mémoire (ou dans un répertoire temporaire) et signale les erreurs sans installer les dépendances.

Chemin de récupération

Si le changement casse le build, restaurez la sauvegarde :

cp app.json.bak.$(date +%Y%m%d%H%M%S) app.json

Mieux encore, utilisez Git pour revenir au dernier bon commit connu :

git checkout -- app.json

Vérification et diagnostics

Après toute sauvegarde ou restauration, vous devez vérifier que le projet est opérationnel. Voici des contrôles pratiques.

Vérifier avec Expo Doctor

Expo fournit un outil de diagnostic intégré :

npx expo-doctor

Sortie attendue lorsque tout va bien :

✔ Check Expo config (app.json/App.config.js) schema
✔ Check that packages match versions required by installed Expo SDK
✔ Check for legacy global CLI installed locally
✔ Check that native modules do not use incompatible support packages
✔ Check that the project does not depend on incompatible web packages
✔ Check package.json for common issues

Si un contrôle échoue, la sortie affiche une erreur spécifique avec des étapes de remédiation.

Valider le bundle JavaScript

Exportez le bundle pour vous assurer qu'il compile sans erreur :

npx expo export --platform all

Un export réussi crée un dossier dist avec index.html, metadata.json et les fichiers de bundle. Vérifiez le code de sortie :

echo $?

Sortie attendue : 0

Si l'export échoue, lisez le message d'erreur ; il pointe souvent vers un module manquant ou une erreur de syntaxe.

Tester l'état restauré localement

Lancez l'application en mode développement :

npx expo start

Utilisez ensuite l'application Expo Go ou un émulateur pour charger le projet. Surveillez le terminal pour la progression du bundling et tout écran d'erreur rouge.

Modes d'échec et récupération

Les sauvegardes et restaurations peuvent échouer de plusieurs façons. Anticipez-les et ayez un plan de récupération.

Modes d'échec courants

1. Sauvegarde incomplète : Vous n'avez sauvegardé qu'une partie du projet (par exemple, src/ mais avez oublié app.json ou package.json).

• Pourquoi cela arrive : Copie manuelle ou commit sélectif.
• Récupération : Recréez les fichiers manquants à partir du contrôle de version si disponible ; sinon, reconstruisez de mémoire et reconfigurez les secrets.

1. Fuite de secret dans la sauvegarde : Vous avez commité un fichier .env ou codé en dur un jeton.

• Pourquoi cela arrive : Absence de règles .gitignore ou copie négligente.
• Récupération : Révoquez immédiatement les identifiants divulgués, supprimez le fichier de l'historique (par exemple, en utilisant git filter-repo ou BFG) et ajoutez .env à .gitignore.

1. Incompatibilité de version après restauration : Les dépendances ou les versions du SDK Expo diffèrent de l'environnement d'origine.

• Pourquoi cela arrive : Restauration sur un système avec des paquets globaux différents ou non-utilisation d'un fichier de verrouillage.
• Récupération : Supprimez node_modules et réinstallez avec npm ci ou yarn install --frozen-lockfile. Utilisez npx expo install --fix pour aligner les versions des paquets avec le SDK.

1. Cache corrompu : Le cache du bundler Metro ou le dossier .expo entraîne des builds obsolètes.

• Pourquoi cela arrive : Builds interrompus ou basculement entre branches.
• Récupération : Videz les caches avec npx expo start -c et supprimez le dossier .expo. Dans les cas extrêmes, supprimez node_modules et package-lock.json et réinstallez.

Vérification après récupération

Après toute récupération, exécutez à nouveau la suite de vérification : expo-doctor, expo export et un contrôle de démarrage local.

Liste de contrôle des opérations

Utilisez cette liste avant chaque opération de sauvegarde ou de restauration. Attribuez chaque élément à un seul responsable (pour les équipes) et révisez-la après chaque version majeure ou mensuellement.

Pièges courants et comment les éviter

Au-delà des modes d'échec, ces erreurs sont fréquentes :

• Compter sur une seule sauvegarde locale : Une panne de disque ou la perte d'un ordinateur portable peut tout détruire. Utilisez un stockage hors site ou dans le cloud avec versionnement (par exemple, S3, GCS, GitHub releases).
• Ignorer eas.json et autres configurations dans les sauvegardes : Les développeurs sauvegardent souvent le code source mais oublient les profils de build, ce qui peut entraîner l'échec des builds EAS.
• Ne pas tester régulièrement la restauration : Une sauvegarde n'est utile que si vous pouvez la restaurer. Planifiez des exercices de restauration périodiques.
• Stocker des secrets en texte brut dans le projet : Utilisez des variables d'environnement et des fichiers .env qui sont gitignorés, ou utilisez la gestion des secrets d'Expo dans EAS.
• Modifier la configuration sans plan de retour en arrière : Gardez toujours une copie de la dernière bonne configuration connue ou utilisez des branches Git.

Conclusion

La sauvegarde et la restauration Expo ne sont utiles que si chaque recommandation est versionnée, observable et réversible. Copier une commande sans vérifier les prérequis et la sortie attendue n'est pas une procédure opérationnelle.

Comme prochaine étape, choisissez une vérification à faible risque (par exemple, exécuter npx expo-doctor), enregistrez l'état actuel, exécutez le contrôle documenté, comparez le résultat avec le signal attendu et examinez les dépendances telles que React Native, Android et votre système CI/CD.

Un flux de travail technique fiable rend l'échec visible, protège les valeurs sensibles, limite les changements à la ressource prévue et définit la vérification de récupération avant qu'un incident ne force la décision.