Xcode Cloud trop lent ne justifie pas, à lui seul, une migration immédiate : cette semaine, comparez un même commit dans les rapports de construction, séparez préparation, compilation, tests et archivage, puis ne déplacez vers un Mac distant que les tâches ralenties par l’environnement temporaire ou par un manque de contrôle de l’hôte.

Cette méthode concerne trois profils : les développeurs Apple qui voient le temps de construction augmenter sans connaître le goulot d’étranglement, les ingénieurs CI qui gèrent des dépendances ou des services persistants, et les responsables qui doivent arbitrer entre consommation de calcul, Mac distant et CI hybride.

01

Le temps total ne suffit pas pour expliquer un Xcode Cloud trop lent

Deux constructions peuvent afficher une durée globale proche et pourtant réclamer des décisions opposées. Dans un cas, la majorité du temps est consommée par l’installation de dépendances. Dans l’autre, la préparation est correcte, mais une matrice de tests, une archive ou plusieurs appareils simulés occupent l’exécution.

Commencez donc par une mesure par phase :

  • attente avant le démarrage du travail ;
  • préparation de l’environnement et exécution du script de clonage ;
  • récupération de Swift Package Manager, CocoaPods, Carthage ou dépôts privés ;
  • compilation du Scheme ;
  • tests unitaires et tests d’interface ;
  • archivage, export et éventuelle remise du résultat.

Les rapports de construction, les journaux d’actions et les données d’utilisation sont les sources prioritaires. Apple documente les actions d’un workflow et les informations disponibles dans les rapports ; utilisez ces données plutôt qu’une estimation faite à partir de la durée affichée dans une interface de suivi. Consultez la documentation Apple sur les actions des workflows Xcode Cloud ainsi que la documentation Apple sur les données d’utilisation.

Pour obtenir une comparaison exploitable, conservez le même commit, le même Scheme, la même configuration de compilation et le même périmètre de tests. Enregistrez au moins un échantillon considéré comme normal et un échantillon réellement lent. Une modification simultanée du code, du nombre de tests et du script de préparation rendrait la conclusion inutilisable.

Rappel d’analyse : ne confondez pas le temps d’attente dans une file, la préparation d’une machine et le temps réellement passé dans xcodebuild. Un déplacement vers un Mac distant ne corrigera pas automatiquement une suite de tests trop large.

Cette première séparation répond aussi à la question de savoir où retrouver le temps de construction Xcode Cloud : cherchez la durée dans le rapport de chaque construction, puis rapprochez-la des journaux d’actions et des données d’utilisation. La durée globale est un indicateur ; le journal par étape est la preuve qui permet d’agir.

02

Les dépendances et les scripts révèlent souvent le premier coût caché

Xcode Cloud travaille avec un environnement de construction temporaire. Une dépendance qui n’est pas préparée de manière déterministe peut donc provoquer une nouvelle récupération, une authentification ou une compilation auxiliaire à chaque exécution. Ce comportement explique pourquoi Xcode Cloud semble parfois « réinstaller » les dépendances à chaque construction : le workflow doit recréer un environnement connu, et il ne peut pas compter sur les fichiers laissés par une construction précédente.

Vérifiez successivement :

  • la présence d’un fichier de verrouillage pour Swift Package Manager ou le gestionnaire utilisé ;
  • la version de CocoaPods, Carthage ou des outils installés dans le script ;
  • l’accès aux dépôts privés et la méthode d’injection des secrets ;
  • les commandes exécutées dans ci_scripts/ ou dans le script de post-clonage ;
  • les outils qui sont installés alors qu’ils ne servent qu’à une étape facultative ;
  • les téléchargements qui se répètent alors qu’ils pourraient être servis par le mécanisme de cache prévu par le workflow.

Apple décrit les méthodes permettant de rendre les dépendances disponibles dans Xcode Cloud dans sa documentation dédiée aux dépendances. La priorité n’est pas de supprimer toutes les installations. Elle est de rendre chaque installation nécessaire, versionnée et observable.

Un script de préparation robuste doit annoncer l’étape en cours, vérifier la présence des outils attendus, échouer avec un code de sortie explicite et éviter les téléchargements silencieux. La sortie 0 indique une réussite de commande ; toute autre sortie doit produire un message permettant d’identifier l’outil, la ressource ou l’authentification en cause. Les scripts personnalisés et leurs limites d’exécution sont détaillés dans la documentation Apple sur les scripts de construction.

Le point d’arrêt qui justifie un Mac distant

L’optimisation reste pertinente lorsque le projet peut être préparé à partir du dépôt, de fichiers de verrouillage et de scripts reproductibles. Le diagnostic change lorsque la construction dépend durablement de l’un des éléments suivants :

  • un service lancé en arrière-plan et conservé entre deux tâches ;
  • une base de données ou un serveur local nécessaire aux tests ;
  • un jeu de données volumineux qu’il serait coûteux de récupérer à chaque exécution ;
  • un certificat, un périphérique ou une configuration d’hôte administrée directement ;
  • une dépendance nécessitant une installation système ou une intervention privilégiée ;
  • un cache que l’équipe doit inspecter, purger ou restaurer elle-même.

Dans ces cas, la question n’est plus seulement « comment accélérer Xcode Cloud ? ». Elle devient : « cette tâche a-t-elle besoin d’un hôte persistant et contrôlable ? ». Si la réponse est oui, déplacez d’abord cette tâche, pas nécessairement toute la chaîne.

03

Cache, compilation propre et tests doivent être mesurés séparément

Une construction propre n’a pas la même valeur diagnostique qu’une construction incrémentale. Elle permet de vérifier la reproductibilité, mais elle ne représente pas toujours le parcours quotidien d’un développeur. À l’inverse, un cache efficace peut masquer une dépendance mal déclarée ou un fichier généré que le dépôt devrait produire explicitement.

Séparez au minimum trois observations :

  • construction après environnement vierge ;
  • construction avec réutilisation du cache autorisé par le workflow ;
  • construction après une modification limitée au code applicatif.

Ne regroupez pas sous le mot « cache » les données dérivées de Xcode, les dépendances téléchargées et les fichiers générés par vos scripts. Ces états n’ont pas le même cycle de vie. Un cache de dépendances peut être valide alors qu’un fichier généré est périmé. Un Derived Data réutilisé peut réduire le temps de compilation tout en masquant une configuration absente du dépôt.

Le référentiel Apple des workflows Xcode Cloud doit servir à vérifier les options réellement activées. Contrôlez en particulier les réglages de compilation propre, les conditions de déclenchement, les actions exécutées et les mécanismes de cache. Ne conservez pas un état persistant simplement parce qu’il rend une exécution plus rapide : si vous ne pouvez pas le reconstruire après une réinitialisation, il devient un risque de livraison.

Les tests lents exigent une autre découpe

Un grand nombre d’appareils simulés, des tests d’interface et une archive lancés sur chaque modification peuvent multiplier le travail sans améliorer le retour immédiat du développeur. La meilleure réponse n’est pas toujours de supprimer des appareils. Elle consiste souvent à répartir les objectifs :

  • validation rapide sur une modification de branche ou une demande de fusion ;
  • tests plus complets sur la branche principale ;
  • validation de compatibilité ou archive dans un workflow déclenché séparément ;
  • campagne complète à un moment planifié, lorsque son coût est acceptable.

Réduire la matrice est cohérent si les appareils retirés couvrent des variantes déjà vérifiées ailleurs. Séparer les workflows est préférable lorsque les tests ont des dépendances, des durées ou des niveaux de criticité différents. Gardez une trace de la couverture perdue : une accélération qui retire précisément le test correspondant au risque principal n’est pas une optimisation.

04

Les déclenchements et les appels réseau créent des files invisibles

Un ralentissement peut provenir de la fréquence des workflows plutôt que d’une action individuelle. Examinez les constructions lancées par chaque événement, les doublons entre branche et demande de fusion, les archives répétées et les tâches qui continuent alors qu’un commit plus récent les a rendues inutiles.

L’annulation automatique des constructions obsolètes peut limiter ce gaspillage lorsqu’une nouvelle modification remplace effectivement l’ancienne. Elle ne doit toutefois pas interrompre une archive ou une validation réglementaire qui doit rester complète. Documentez chaque condition de déclenchement, puis associez-la à un objectif précis : retour développeur, régression de branche principale ou préparation de publication.

Les scripts réseau sont une autre source de longue traîne. Une commande peut attendre silencieusement une réponse de dépôt, d’API ou de stockage. Pour chaque appel, ajoutez :

  • une ligne de journal avant et après l’opération ;
  • une vérification du code de retour ;
  • une stratégie de nouvelle tentative limitée ;
  • une sortie explicite lorsque l’authentification échoue ;
  • une protection contre l’affichage de jetons ou de certificats.

Xcode Cloud peut fournir des variables liées à son environnement réseau. Vérifiez leur nom et leur utilisation dans la référence Apple des variables d’environnement. Une construction qui dépend d’un réseau privé, d’un processus permanent ou d’un fichier conservé entre les exécutions devient un candidat naturel pour un Mac distant ou pour une architecture hybride.

05

La décision se prend tâche par tâche, pas avec une migration totale

Le tableau suivant sert à transformer les observations en décision. Il ne remplace pas les journaux : il indique quelle conclusion prendre lorsque les faits sont établis.

Situation observée Action prioritaire Solution la plus cohérente Condition de sortie
Le temps est surtout consommé par un script inutile ou une dépendance mal verrouillée Simplifier, versionner et journaliser la préparation Continuer avec Xcode Cloud Le temps de préparation devient stable sur le même type de commit
La compilation est correcte, mais la matrice de tests domine Séparer les workflows et réduire les validations répétées Continuer avec Xcode Cloud, éventuellement avec une exécution complète distincte Chaque niveau de test possède un objectif et un déclencheur clair
Un service, un cache inspectable ou un état de machine doit persister Reproduire uniquement la tâche concernée sur un hôte contrôlé Migrer cette tâche vers un Mac distant La tâche fonctionne après redémarrage et ses dépendances sont documentées
La publication utilise bien Xcode Cloud, mais les tests avancés exigent un contrôle local Conserver la publication et déplacer les tests spécialisés CI hybride Les artefacts, statuts et journaux circulent entre les deux environnements
Les erreurs viennent d’un réseau privé ou d’une authentification externe Identifier les appels et leurs contraintes d’accès Mac distant ou réseau dédié selon le besoin Les échecs sont visibles et récupérables sans intervention manuelle

Un Mac distant est donc pertinent lorsque vous devez maîtriser l’hôte, les services, les fichiers persistants ou les permissions. Il est moins pertinent si le véritable défaut est un Scheme trop large, un script non déterministe ou une matrice de tests mal déclenchée.

Pour une équipe qui veut vérifier cette hypothèse sans acheter immédiatement une machine, un environnement de développement Mac distant à valider permet de tester une tâche isolée avec votre propre dépôt, vos scripts et votre méthode d’authentification. La validation doit porter sur la reproductibilité, la lisibilité des journaux, la récupération après redémarrage et le travail d’administration nécessaire.

06

Procédure de diagnostic en cinq étapes

Première étape : figer le périmètre

Choisissez un commit représentatif, un Scheme et une configuration. Notez les tests, l’archive et les scripts réellement exécutés. N’ajoutez pas de modification fonctionnelle pendant la comparaison.

Deuxième étape : exporter les preuves

Conservez le rapport de construction, les journaux d’actions et les données d’utilisation associées. Relevez séparément l’attente, la préparation, la compilation, les tests et l’archivage.

Troisième étape : instrumenter les scripts

Ajoutez des marqueurs avant et après chaque téléchargement, installation, génération de fichier et appel distant. Masquez les secrets. Vérifiez systématiquement les codes de retour.

Quatrième étape : réduire sans dégrader la couverture

Désactivez uniquement les installations inutiles, les tests dupliqués ou les déclenchements sans objectif clair. Comparez une construction propre et une construction réutilisant le cache. Si le résultat varie fortement, cherchez l’état caché plutôt que de conclure à un gain durable.

Cinquième étape : lancer un essai ciblé sur Mac distant

Ne transférez pas toute la plateforme. Commencez par la tâche qui réclame un service persistant, un cache contrôlé ou un accès système. Utilisez le même commit et le même Scheme, puis testez une réexécution après redémarrage. Si l’essai exige des opérations manuelles permanentes, le coût d’exploitation doit entrer dans la décision.

Expérience de terrain : un nœud distant n’est utile que si son état est compréhensible par une autre personne que son auteur. Documentez le compte de service, les certificats, les chemins de scripts, les secrets, les ports nécessaires et la procédure de remise en service.

07

Quand continuer, migrer ou adopter deux environnements

Continuez avec Xcode Cloud lorsque la chaîne reste déclarative, que les dépendances sont récupérables depuis le dépôt, que les tests peuvent être séparés et que les rapports suffisent à diagnostiquer les échecs. Dans ce cas, acheter davantage de capacité sans corriger les déclenchements risque seulement d’augmenter un coût mal attribué.

Migrez une tâche vers un Mac distant lorsque l’environnement temporaire recrée trop souvent un état coûteux, lorsqu’un service doit rester actif ou lorsque l’équipe doit contrôler l’hôte, ses permissions et ses fichiers. Le déplacement doit rester limité au périmètre qui justifie ce contrôle.

Adoptez deux environnements lorsque Xcode Cloud offre une publication ou une validation standard fiable, mais que les tests spécialisés, les intégrations privées ou les scénarios audio, vidéo et design nécessitent une machine persistante. Cette organisation évite de transformer une exigence particulière en contrainte pour toute la chaîne.

Les solutions ont aussi des inconvénients :

  • Xcode Cloud réduit l’administration d’infrastructure, mais limite le contrôle direct de l’environnement ;
  • un Mac distant donne davantage de contrôle, mais impose la gestion des comptes, des secrets, des mises à jour et de la récupération après panne ;
  • une CI hybride conserve de la souplesse, mais demande une convention claire pour les artefacts, les statuts et les responsabilités.

Si vos journaux montrent que le ralentissement vient surtout des initialisations répétées ou de l’absence d’un hôte persistant, louer temporairement un Mac distant est une manière prudente de comparer les deux approches avant un engagement durable. Vous pouvez aussi consulter les tarifs de location de Mac distant pour estimer cette expérimentation, sans la confondre avec une économie garantie : le coût réel inclut la maintenance, la surveillance et le temps d’exploitation.

Le choix opposé comporte lui aussi des limites. Rester uniquement sur Xcode Cloud peut vous laisser dépendant d’un environnement temporaire, sans service permanent ni contrôle fin des caches. Acheter un Mac dédié immobilise du capital, exige une maintenance physique et ne convient pas toujours à une équipe qui veut tester une architecture pendant une courte période. Un Mac distant loué par VpsMesh est donc surtout intéressant pour une tâche temporaire, une comparaison contrôlée ou une CI hybride ; pour une charge stable et très intensive ou pour un besoin de périphériques physiques, l’achat et l’administration d’un hôte dédié peuvent rester plus cohérents.

Cette semaine, ne migrez pas sur la base d’une seule construction lente. Mesurez d’abord les phases, corrigez les déclenchements et les dépendances, puis faites tourner sur un Mac distant uniquement le travail dont les journaux démontrent le besoin. Vous pourrez alors décider avec des preuves entre optimisation, migration partielle et double chaîne CI.