Les principes sont basés sur la méthodologie bien connue de heroku , adaptée aux réalités du développement ayios (Manque de conteneurs, critiques qui prennent plusieurs jours et ralentissent le déploiement, Xcode ne fonctionne que sur un coquelicot).
Cet article est une courte introduction, la série complète peut être trouvée sur le facteur iOS , une traduction russe est également disponible. Le projet open source de facteur iOS sur github est constamment affiné et accueille de nouvelles idées. J'ai également participé à son développement. Le projet a été fondé par Felix qui est le créateur de fastlane .
TL; DR
- Dépendances : Doit être spécifié explicitement et spécifiquement (version de Xcode, CocoaPods, version des dépendances dans le podfile). Cela permet à un nouveau développeur de jouer la build sur n'importe quel Mac. Répétez également l'assemblage utilisé il y a 6 mois.
- Configuration : Aucune configuration dans le code, livré avec l'application et possibilité de mise à jour par voie aérienne
- Développement d'application / parité de travail : Gardez les environnements de développement, de transfert et de production aussi similaires que possible
- Déploiement : automatisez le déploiement pour pouvoir le libérer de n'importe quelle machine.
- Local contre Beck : gardez votre application iOS universelle pour pouvoir travailler sans backend autant que possible
- API rétrocompatibles : ne pensez pas que chaque utilisateur passe à la dernière version
- Gestion des versions des applications : automatisez les mises à niveau des versions et des builds
- Rollbacks : Rollback assembly qui cause des problèmes
- Stockage de données : suivez les recommandations d'Apple pour le stockage de données
L'application déclare toutes ses dépendances de manière complète et précise à l'aide du manifeste de déclaration de dépendance.
Cela inclut une version spécifique de Swift, Xcode, CocoaPods, Carthgae et Fastlane. En outre, toutes les dépendances dans podfile et cartfile doivent spécifier une version spécifique.
L'un des avantages de la déclaration explicite des dépendances est qu'il facilite la configuration des applications pour les nouveaux développeurs.
À l'aide de la spécification de dépendances spécifiques, vous pouvez reproduire la build qui a été utilisée il y a 6 mois, sachant qu'elle sera construite car la build utilisera la même version de Xcode, CocoaPods et Swift.
Limitation - Étant donné que le développement iOS ne peut pas être contenu dans un conteneur, car il est déjà utilisé pour le développement Web, nous sommes limités aux outils tiers essayant de répondre à cette exigence jusqu'à ce qu'Apple fournisse une solution officielle. Il existe une solution commerciale (fermée) tierce appelée Veertu qui vous permet de créer des environnements MacOS virtuels sur du matériel Apple.
Le code ne dépend pas de l'environnement, mais la configuration dépend. Par conséquent, le code doit être stocké dans le référentiel et la configuration dans l'environnement. Vérifier si la configuration et le code d'application sont correctement séparés est le fait que la base du code d'application peut être librement disponible à tout moment sans compromettre les données privées.
Il existe de nombreuses façons d'entrer des valeurs de configuration au moment de la génération.
- Fichiers de configuration (fichiers JSON ou YAML)
- cocoapods-keys pour masquer les clés et les appliquer à votre application iOS pendant la construction
- Solution personnalisée (par exemple en utilisant la phase de construction)
Étant donné que les déploiements sur la plate-forme iOS sont beaucoup plus lents que sur les serveurs, vous devrez peut-être un moyen de mettre à jour la configuration par liaison radio (OTA) pour répondre rapidement aux problèmes.
Les mises à jour de la configuration OTA vous permettent de:
- Exécutez des tests A / B pour activer certaines fonctions ou modifications d'interface utilisateur pour une partie seulement des utilisateurs actifs.
- Modifier les clés d'API
- Mettre à jour des hôtes Web ou d'autres URL qui ont changé
- Désactiver à distance les fonctionnalités ou masquer les boutons
Certaines approches potentielles lors de la mise en œuvre des mises à jour OTA sont:
Historiquement, il existe des différences importantes entre le développement (le développeur apporte des modifications en direct sur le déploiement local de l'application) et le fonctionnement de l'application (déploiement de l'application dans l'App Store avec accès par les utilisateurs finaux).
Ces différences apparaissent dans trois domaines:
- Décalage horaire
- Différence de personnel
- Écartement des outils:
Solution:
- Faites le petit décalage horaire: le développeur peut écrire le code, et il sera déployé en quelques heures voire quelques minutes.
- Réduisez les différences de personnel: le développeur qui a écrit le code participe activement à son déploiement et surveille son comportement pendant l'exécution de l'application.
- Réduisez les différences d'outils: gardez l'environnement de développement et de travail de votre application aussi similaire que possible.
Comme décrit dans le principe des dépendances , le référentiel de code doit inclure toutes les dépendances nécessaires pour créer, tester et déployer l'application iOS.
Malheureusement, étant donné que Xcode devrait fonctionner sur MacOS, nous ne pouvons pas utiliser de conteneurs comme sur le Web. L'exécution de macOS dans un environnement virtuel est lourde de problèmes techniques et juridiques.
À l'heure actuelle, la meilleure approche que les développeurs iOS peuvent utiliser est la suivante:
- Automatisez l'installation de Xcode avec xcode-install
- Utilisez le fichier de version .xcode pour spécifier la version exacte de Xcode
- Définissez toutes les dépendances dans les fichiers de configuration (voir Facteur de dépendances)
- Automatisez l'ensemble du processus de déploiement à l'aide de Fastlane
- Automatisez la signature de l'application (codesigning.guide)
- Libérez souvent, idéalement sur un horaire hebdomadaire
De nombreuses entreprises utilisent le concept de Release trains: un planning qui libère une nouvelle version de votre application. Tout le code qui a été fusionné avec votre branche principale (maître ou version) au moment où le train de versions «quitte» sera envoyé à l'App Store. Cette approche est mise en œuvre par la plupart des grandes applications iOS.
Ces dernières années, certaines équipes de développement ont commencé à utiliser des approches qui nécessitent moins d'efforts de développement en réduisant la qualité de l'expérience utilisateur, en déplaçant plus de logique vers le backend et en faisant de l'application iOS un client léger qui affiche les résultats du serveur.
Une application doit faire autant de logique métier et de calcul sur l'appareil que possible pour un certain nombre de raisons:
- Confidentialité: évitez d'envoyer des données à un serveur distant
- Vitesse: l'envoi de données au serveur et l'attente d'une réponse prennent du temps et peuvent entraîner un plantage (par exemple, une mauvaise connexion Wi-Fi)
- Utilisation des données: les utilisateurs ont souvent des limites de données mensuelles
- Mise à l'échelle: si votre application devient populaire, vous êtes responsable de la mise à l'échelle des services backend.
- Autonomie de la batterie: le mobile coûte cher
- Fiabilité: les connexions LTE / 3G sont encore médiocres dans certains pays
Si votre application nécessite une connexion Internet pour toutes les fonctionnalités (par exemple, une application de réseautage social ou une application de partage de voyage), elle devrait toujours fonctionner (en mode lecture seule) sans connexion Internet pour accéder aux données historiques (par exemple, récentes voyages, communications directes récentes).
Bien que la plupart de vos utilisateurs soient mis à jour vers la dernière version dans quelques semaines, il y aura toujours des utilisateurs qui ne le feront pas. Cela peut avoir plusieurs raisons. Cela est souvent dû à la version d'iOS utilisée, qu'ils ne peuvent pas toujours mettre à jour en raison de l'âge de l'appareil.
Le concept de base est que vous ne mettez pas à jour l'API existante, mais en en ajoutant une nouvelle et en la laissant fonctionner en parallèle
https://your-api.com/1.0/drivers.json https://your-api.com/1.1/drivers.json
La version et le numéro de build sont utilisés ensemble pour identifier une application spécifique dans l'application.
- Numéro de version
(CFBundleShortVersionString) - (CFBundleShortVersionString) comme version dans Xcode - Numéro de build
(CFBundleVersion) - (CFBundleVersion) tant que build dans Xcode
Dans le développement iOS d'aujourd'hui, il n'y a aucune raison de modifier manuellement ces chiffres. Au lieu de cela, vous avez besoin d'un système fiable et automatisé pour maintenir les versions à jour.
Xcode a un outil intégré appelé agvtool .
Au départ, l'App Store n'autorise pas les restaurations, donc cette section décrit comment obtenir des résultats similaires en utilisant les méthodes disponibles.
Versions de jalons - À l'aide de versions de jalons, vous pouvez déployer lentement l'assemblage vers la prod, en commençant par un petit nombre d'utilisateurs actifs.
Cependant, même dans le cas de versions progressives, il est impossible de rappeler complètement l'assembly: une fois l'assembly installé sur l'appareil de l'utilisateur, la seule façon de modifier cet assembly est de distribuer une nouvelle version avec un numéro de version / build mis à jour.
Comme pour les versions progressives, les assemblys App Store et TestFlight ne peuvent être mis à jour qu'en suivant ces étapes:
- Revenez à votre système de contrôle de version dans l'état dans lequel vous souhaitez revenir.
- Augmentez la version et / ou le numéro de build de votre projet
- Créez et signez votre candidature
- Distribuez votre application via le service bêta ou l'App Store
- L'utilisateur doit mettre à jour l'application sur son téléphone.
Les étapes ci-dessus peuvent être effectuées manuellement, mais il est recommandé que le processus soit entièrement automatisé afin de pouvoir répondre rapidement.
Alternative: re-signer l'ancienne construction
- Accéder à l'ancien assembly (fichier .ipa) avant l'introduction de la régression
- Mettez à jour le numéro de version / build dans le fichier Info.plist
- Ancienne construction «Signer à nouveau»
- Distribuez-le comme une nouvelle version
Cependant, la «signature» d'applications iOS crée souvent plus de problèmes, notamment parce que les outils de ligne de commande Xcode n'offrent pas un bon moyen de le faire.
Le stockage des données et des configurations conformément aux recommandations d'Apple est essentiel au cycle de vie de votre application, en particulier en ce qui concerne la synchronisation iCloud, la mise à niveau vers un nouveau téléphone et la restauration de votre téléphone à partir d'une sauvegarde.
Assurez-vous de suivre les directives de stockage de données Apple iOS officielles:
Documents : utilisez ce répertoire pour du contenu personnalisé, il sera archivéCaches : utilisez ce répertoire pour les données qui peuvent être récupérées.tmp : utilisez ce répertoire pour les fichiers temporaires- Utilisez la propriété
do not back up pour les fichiers
Ne stockez jamais d'informations confidentielles sur l'utilisateur (telles que des mots de passe ou des sessions) dans ces répertoires. Utilisez plutôt l'API Trousseau.