Configurer une build iOS React Native dans App Center

  • Article

Important

Visual Studio App Center doit être mis hors service le 31 mars 2025. Bien que vous puissiez continuer à utiliser Visual Studio App Center jusqu’à ce qu’il soit entièrement mis hors service, il existe plusieurs alternatives recommandées vers lesquelles vous pouvez envisager de migrer.

En savoir plus sur les chronologies et les alternatives de support.

App Center peut générer des applications React Native écrites dans React Native version 0.34 ou ultérieure.

Pour créer une application React Native pour iOS :

  1. Connectez-vous à votre compte de service de dépôt (par exemple : Azure DevOps, Bitbucket, GitHub ou VSTS).
  2. Sélectionnez un dépôt et une branche où réside votre application.
  3. Configurez le projet ou l’espace de travail de la build et le schéma que vous souhaitez générer.

Notes

Pour que l’application s’exécute sur un appareil réel, la build doit être signée avec un profil d’approvisionnement valide et un certificat.

1. Liaison de votre dépôt

Tout d’abord, connectez votre compte de service de dépôt à App Center. Une fois votre compte connecté, sélectionnez le dépôt où se trouve votre projet iOS. Vous devez disposer des autorisations d’administrateur et de tirage pour le dépôt.

2. Sélection d’une branche

Après avoir sélectionné un dépôt, sélectionnez la branche que vous souhaitez générer. Par défaut, toutes les branches actives sont répertoriées.

3. Configuration de votre première build

Avant votre première build, le projet React Native doit être configuré.

3.1. Project

Sélectionnez le fichier de package.jsonvotre projet . App Center détecte automatiquement le projet/l’espace de travail Xcode associé.

3.2. Version Xcode

Sélectionnez la version Xcode sur laquelle exécuter la build dans la liste déroulante. Si le bouton bascule « Utiliser le système de build hérité » est On, le système de build hérité est utilisé quels que soient les paramètres du projet ou de l’espace de travail. Si le bouton bascule « Utiliser le système de build hérité » est Off, la configuration du système de build à partir des paramètres du projet ou de l’espace de travail sera utilisée.

Notes

  • Le paramètre d’espace de travail doit être approuvé dans le dépôt
  • Si le paramètre d’espace de travail n’est pas validée, le système de build moderne est utilisé

3.3. Version de Node.js

Sélectionnez la version Node.js à utiliser pour la build. En savoir plus sur la sélection de Node.js version

3.4. Déclencheurs de génération

Par défaut, une nouvelle build est déclenchée chaque fois qu’un développeur envoie un push à une branche configurée. Si vous préférez déclencher une nouvelle génération manuellement, vous pouvez modifier ce paramètre dans le volet de configuration.

3.5. Incrémenter le numéro de build

Lorsque cette option est activée, le CFBundleVersion dans la liste Info.plist du projet de votre application s’incrémente automatiquement pour chaque build. La modification se produit avant la génération et ne sera pas validée dans votre dépôt.

3.6. Signature de code

Une build réussie produit un .ipa fichier. Pour installer la build sur un appareil, la build doit être signée avec un profil et un certificat d’approvisionnement valides. Pour signer les builds produites à partir d’une branche, activez la connexion du code dans le volet de configuration et chargez un profil d’approvisionnement (.mobileprovision fichier) et un certificat valide (.p12), ainsi que le mot de passe du certificat.

Les paramètres de votre projet Xcode doivent être compatibles avec les fichiers que vous chargez. En savoir plus sur la signature de code iOS d’App Center et la documentation Apple Developer.

La signature d’applications avec des extensions d’application ou watchOS nécessite un profil d’approvisionnement supplémentaire par extension.

3.7. Lancer votre build réussi sur un appareil réel

Utilisez le fichier nouvellement produit .ipa pour tester si votre application démarre sur un appareil réel ; le test de lancement ajoute environ 10 minutes supplémentaires au temps de génération total. En savoir plus sur la configuration des tests de lancement.

3.8. CocoaPods

App Center analyse la branche sélectionnée et s’il trouve un Podfile, il effectue automatiquement une pod install étape au début de chaque build. Cela garantit que toutes les dépendances sont installées.

3.9. Distribuer à un groupe de distribution

Configurez chaque build réussie à partir d’une branche pour qu’elle soit distribuée à un groupe de distribution créé précédemment. Ajoutez un nouveau groupe de distribution à partir de la section Distribuer. Il existe toujours un groupe de distribution par défaut appelé « Collaborateurs » qui inclut tous les utilisateurs qui ont accès à l’application.

Une fois que vous avez enregistré la configuration, une nouvelle génération est automatiquement démarrée.

4. Générer des résultats

Les builds peuvent se trouver dans l’un des états suivants :

  • mis en file d’attente : la build est mise en file d’attente en attente des ressources disponibles
  • build : la build exécute et exécute des tâches prédéfinies
  • réussi : la build s’est terminée avec succès
  • échec : la build s’est terminée sans succès ; résoudre les problèmes en téléchargeant et en inspectant le journal de build
  • annulé : la build a été annulée par l’action de l’utilisateur ou a expiré

4.1. Journaux d’activité de génération

Pour une build terminée (réussie ou ayant échoué), téléchargez les journaux pour en savoir plus sur la façon dont la build s’est déroulée. App Center fournit une archive avec les fichiers suivants :

|-- 1_build.txt (this is the general build log)
|-- build (this folder contains a separate log file for each build step)
    |-- <build-step-1> (e.g. 2_Get Sources.txt)
    |-- <build-step-2> (e.g. 3_Pod install.txt)
    |--
    |-- <build-step-n> (e.g. n_Post Job Cleanup.txt)

Les journaux de build (situés dans le build/ répertoire de l’archive) sont utiles pour résoudre les problèmes et comprendre quelle étape et pourquoi la build a échoué.

4.2. L’application (.ipa)

Le .ipa fichier est un fichier d’archive d’application iPhone qui contient l’application iOS.

  • Si la build a été signée correctement, vous pouvez installer le .ipa fichier sur un appareil réel inclus dans le profil d’approvisionnement utilisé lors de la signature. Pour plus d’informations sur la signature et la distribution de code avec App Center, consultez la documentation de signature de code iOS d’App Center.
  • Si la build n’est pas signée pendant la génération, les développeurs peuvent signer le fichier (localement à l’aide .ipa de codesign) ou l’utiliser à d’autres fins (par exemple, charger vers le service test pour les tests de l’interface utilisateur sur des appareils réels ou s’exécuter dans le simulateur).
  • Les builds non signées ne produisent pas de .ipa fichier. L’artefact d’une build non signée est le .xcarchive fichier, qui peut être utilisé pour générer un .ipa fichier avec l’organisateur Xcode Archives.

4.3. Les cartes sources et les fichiers de symboles

Lors de la génération d’une application iOS React Native, une carte source JavaScript et un ou plusieurs .dsym fichiers sont générés automatiquement à chaque build et peuvent être téléchargés une fois la build terminée.

  • si vous avez précédemment intégré le Kit de développement logiciel (SDK) App Center dans votre application avec le module rapport d’incident activé, la balise de signalement d’incidents nécessite ce .dsym fichier et la carte source JavaScript pour qu’une build affiche des rapports d’incident lisibles par l’utilisateur (symboliques).
  • si vous avez déjà intégré un autre KIT de développement logiciel (SDK) à des fins de création de rapports d’incidents dans votre application, le service correspondant nécessite que le .dsym fichier et la carte source JavaScript affichent des rapports d’incident lisibles par l’homme (symboliques).

Gardez à l’esprit que le .dsym fichier ne change pas lors de la signature du code ..ipa Si vous décidez de signer la build ultérieurement, le .dsym généré avant la signature de code est toujours valide.

Si le KIT de développement logiciel (SDK) de plantage est inclus dans cette application, les symboles iOS et les cartes sources sont envoyés au service App Center Crashs. Les symboles activent des rapports d’incident lisibles (symboliques) à la fois dans la pile native et JavaScript.

5. Conseils de génération

5.1. Yarn

Yarn est un remplacement plus rapide et plus déterministe pour npm. Si un yarn.lock fichier est présent dans votre dépôt à côté de package.json, App Center utilise Yarn, ce qui se fait yarn install au début de la build. Dans le cas contraire, il fera npm install.

5.2. Scripts de build personnalisés

Il existe plusieurs options pour exécuter des scripts avant l’exécution des commandes de build par défaut d’App Center.

  • Créez un script post-installation dans le fichier de package.json votre projet. Cette opération s’exécute automatiquement après l’installation de vos dépendances.

      "scripts": {
    ...
    "postinstall" : "eslint ./" // other examples: "node ./postinstall.js" or "./postinstall.sh"
  },

  • Écrivez un script d’interpréteur de commandes à l’aide de la fonctionnalité de scripts de build personnalisés d’App Center.

    #!/usr/bin/env bash

# Example: Authenticate with private NPM registry
echo "//registry.npmjs.org/:_authToken=$NPM_AUTH_TOKEN" > ~/.npmrc

# Example: Create a file that's not in version control (from base64 encoded environment variable)
base64 -d <<< "$MY_FILE_CONTENTS" > ios/SuperSecretFile.txt