Le .zip d'un projet Flutter

En résumé : zippez votre dossier de projet tel que Flutter l'a créé, en y laissant vos fichiers de configuration et vos éventuelles dépendances privées — et sans les dossiers de build ni les caches.

Ce que l'archive doit contenir

• pubspec.yaml — la carte d'identité du projet, à la racine de l'archive.
• pubspec.lock — recommandé : il fige les versions exactes de vos dépendances, pour un build identique à celui que vous testez en local.
• lib/ — votre code Dart.
• android/ et ios/ — les dossiers plateforme générés par Flutter (icônes, configuration native, permissions…). Le build en a besoin, même si vous n'y avez jamais touché.
• Vos assets — images, polices et autres fichiers déclarés dans pubspec.yaml.
• Les fichiers de configuration utilisés par l'app, s'ils existent : google-services.json (Firebase Android), GoogleService-Info.plist (Firebase iOS), fichiers .env lus au moment du build, etc.

Une archive bien formée ressemble à ceci :

mon-app.zip
├── pubspec.yaml
├── pubspec.lock
├── lib/
├── android/
├── ios/
├── assets/
└── packages/          ← vos éventuels packages locaux (voir ci-dessous)

Dépendances locales et privées : à inclure

Nous compilons uniquement ce qui est dans l'archive. La machine de build n'a accès ni à votre ordinateur, ni à vos dépôts git privés. Donc :

• Les dépendances path: (packages locaux) doivent être incluses dans le .zip, avec des chemins relatifs qui restent valables à l'intérieur de l'archive. Si votre pubspec.yaml pointe vers ../mon-package, ce chemin sort de l'archive : déplacez le package dans le projet (par ex. packages/mon-package) et mettez le chemin à jour.
• Les dépendances venant d'un git privé ou d'un registre privé doivent être copiées dans le projet et référencées en path:, car le build ne peut pas s'y connecter.

Ce que Releasely télécharge pour vous

Inutile de les mettre dans l'archive — elles sont récupérées automatiquement pendant le build :

• les packages pub.dev (flutter pub get est exécuté pour vous) ;
• les CocoaPods iOS (pod install tourne sur le Mac de build) ;
• le SDK Flutter lui-même.

Ce que vous pouvez exclure

Ces dossiers sont régénérés au build — les inclure ne fait qu'alourdir l'envoi :

• build/ et .dart_tool/ — les artefacts et caches de compilation ;
• .git/ — l'historique de votre dépôt ;
• ios/Pods/ et android/.gradle/ — les caches des dépendances natives ;
• .idea/, *.iml, .vscode/ — la configuration de votre éditeur.

Sur macOS ou Linux, cette commande crée une archive propre depuis la racine du projet :

zip -r mon-app.zip . -x "build/*" ".dart_tool/*" ".git/*" "ios/Pods/*" "android/.gradle/*" ".idea/*" ".vscode/*"

Signature : jamais dans le .zip

Taille et numéro de build

• 2 Go maximum par archive — largement suffisant pour un projet sans dossiers de build.
• Le numéro de build est incrémenté automatiquement à partir du dernier build connu ; un champ sur l'écran Upload permet de le forcer si vous devez rattraper un numéro déjà utilisé sur les stores.

Et ensuite ?

Une fois l'archive envoyée, Releasely lance le build cloud (iOS et/ou Android selon votre projet) et le binaire produit rejoint automatiquement votre prochaine version.