Déploiement par environnement
Formulaire symfony par la pratique
-
Objectifs
- Comprendre la notion d’environnements d’application
- Comprendre le fonctionnement de la signature de paquets applicatifs pour iOS et Android
- Connaître les éléments indispensables pour déployer
-
Présentation
- Avant de publier sur les magasins d’applications comme l’AppStore, il est essentiel de comprendre les principes fondamentaux liés au déploiement des applications sur Android et iOS. Pour cela, nous allons explorer la configuration de l’environnement et la signature des packages applicatifs. Ces processus varient significativement selon la plateforme, donc nous allons examiner les particularités d’Android et d’iOS.
-
Le concept d’environnements dans Flutter
- Lorsque vous développez une application mobile avec Flutter, vous devez immédiatement considérer la notion d’environnement. Pendant la phase de développement, il est crucial d’activer certains outils de développement et éventuellement de déboguer le code. Cependant, une fois que l’application est prête à être déployée en production, il est essentiel d’optimiser la performance en supprimant les modules de développement inutilisés, tels que le débogueur.
- Flutter propose par défaut deux environnements : un environnement de développement avec les outils de développement activés, et un environnement de production pour les déploiements finaux. Chacun de ces environnements est associé à une configuration spécifique permettant de générer un build adapté.
- Sur Android, la gestion des builds et des environnements se fait via Gradle, un outil permettant de gérer les séquences de scripts et de configuration pour les déploiements Android.
- Sur iOS, ces aspects sont gérés à travers Xcode, l’environnement de développement d’Apple.
- Sur iOS, chaque environnement est associé à un profil de provisionnement (que nous devons générer), tandis que sur Android, nous avons besoin d’un keystore pour signer le paquet applicatif. Bien que ces deux technologies soient différentes, elles répondent à la même problématique : certifier l’origine de notre application.
-
La gestion des builds et des environnements sur Android
- La gestion des builds et des environnements sur Android est réalisée via Gradle, un outil robuste qui permet de gérer les séquences de scripts et la configuration nécessaire pour les déploiements sur la plateforme Android. Gradle offre une flexibilité et une efficacité significatives dans la construction et la personnalisation des applications Android, en permettant aux développeurs de définir des configurations spécifiques pour chaque environnement, que ce soit pour le développement, la production ou d’autres contextes spécifiques. Grâce à Gradle, les développeurs peuvent automatiser les tâches de build, gérer les dépendances et adapter le processus de compilation selon les besoins de leur projet Android.
-
Le keystore d’Android
- Sur Android, le keystore est un fichier semblable, c’est-à-dire une clé privée permettant de certifier la provenance d’un paquet applicatif. En l’utilisant au moment du build, on signe notre application et on certifie donc que l’on est bien l’auteur de cette dernière. La procédure est décrite dans la documentation React Native pour les applications standalone https://reactnative.dev/docs/signed-apk-android, mais, dans le cas d’Expo, nous pouvons également lui déléguer cette tâche.
- Il faut bien garder cette clé, car, pour pouvoir déployer des mises à jour, il faudra signer les nouveaux builds avec cette même clé, sans quoi Google Play refusera l’application.
- Là aussi, tout se passe dans App.json.
- Il est crucial de conserver cette clé en sécurité, car pour déployer des mises à jour ultérieures, les nouveaux builds doivent être signés avec la même clé. Sans cela, Google Play refusera l’application.
- Ces opérations se déroulent également dans le fichier App.json.
- Dans le contexte d’Expo, pour mettre en ligne notre application, nous devons lui associer une image d’identification ainsi qu’un titre. De plus, sur chaque plateforme de distribution, nous devons fournir des informations détaillées sur l’application et des captures d’écran pour présenter son fonctionnement.
- Toutes ces configurations sont centralisées dans le fichier App.json à la racine du projet Expo. Des champs tels que « name » et « icon » définissent respectivement le nom de l’application et son icône, tandis que « version » spécifie la version de l’application, tous trois étant obligatoires.
- Ensuite, il y a des configurations spécifiques à iOS et Android, telles que le « package name » ou l’identifiant de bundle mentionné précédemment. Il est également important de noter les concepts de « buildNumber » et « versionCode » qui servent à différencier les différentes versions binaires de l’application. Il est impératif de les incrémenter à chaque build chargé sur l’App Store ou Google Play Store.
