Le cas d’un pipeline de build iOS
Commencez par vérifier qui utilise la machine, puis évaluez les coûts et le temps d’exploitation. XCRent fournit des Mac mini physiques dédiés, non virtualisés, avec une facturation à la journée, à la semaine, au mois ou au trimestre. Pour savoir si cette solution convient à votre projet, fiez-vous au même code source et aux mêmes journaux de build.
Location à la journée dès $21.7. Testez d’abord, prolongez ensuite si besoin.
Comparez les types de service, pas les performances de puces différentes. Pour une plateforme partagée, vérifiez les tarifs, les files d’attente et les limites de ressources propres à l’offre choisie. Avec un Mac acheté, prévoyez aussi le déploiement et la gestion au quotidien.
| Critère | Mac cloud dédié en location | Matériel acheté | Machine virtuelle partagée |
|---|---|---|---|
| Coût | XR Build 16 dès $108.3/mois. Le coût de location du nœud est clairement défini ; l’équipe doit toujours gérer le projet, les certificats et le pipeline. | Achat initial, auquel s’ajoutent l’espace, le réseau, l’électricité, les sauvegardes et la gestion du matériel. Ne comparez pas uniquement le prix d’achat au coût de location. | Facturation parfois à la minute ou à la tâche. Vérifiez si le démarrage, l’installation des dépendances, l’attente et le stockage des artefacts sont facturés, au lieu de regarder uniquement le coût d’une compilation. |
| Mise à disposition | Un nœud physique est attribué après la commande, avec macOS et Xcode préinstallés. Consultez l’état d’attribution et la disponibilité réelle dans la console. | Il faut acheter et recevoir le matériel, l’installer, puis configurer l’accès à distance, la chaîne d’outils et le compte de build. Le délai de mise en service dépend de votre équipe. | Un environnement peut généralement être créé à la demande, mais les configurations disponibles, le démarrage et les files d’attente dépendent des ressources et des règles de la plateforme. |
| Exclusivité | Le nœud physique entier est réservé à un seul locataire. Xcode, les simulateurs et le trousseau ne partagent pas le même système avec d’autres locataires. | Le matériel appartient à l’équipe. C’est à elle de décider s’il est réservé au build ou partagé avec les postes de développement. | Une machine virtuelle peut bénéficier d’une isolation au niveau système, mais les ressources physiques sous-jacentes peuvent être partagées entre plusieurs locataires. Une VM n’équivaut pas à une machine entière réservée. |
| Évolutivité | Demandez une configuration supérieure dans la console ou ajoutez un SSD de +1TB / +2TB. Vérifiez au préalable les modalités de mise à niveau et les besoins de migration des données. | Il faut acheter du matériel supplémentaire ou modifier la configuration. L’ajout de machines implique aussi de gérer le réseau, l’accès à distance et l’environnement de build. | Les possibilités dépendent des configurations et des fonctions de la plateforme. Vérifiez la mémoire, le stockage, la persistance du cache et les limites de concurrence ; ne partez pas du principe que tout est extensible. |
| Cache et état | Gérez vos répertoires de code source, caches de dépendances et DerivedData. Définissez une politique de nettoyage pour éviter de saturer le disque système. | Vous gérez le cache et l’état comme vous le souhaitez, mais aussi les alertes disque, les sauvegardes et les restaurations. | Vérifiez si l’environnement est supprimé à la fin de la tâche, comment le cache est restauré, si le temps de restauration est facturé et quels répertoires peuvent être conservés. |
| Exploitation | La plateforme gère le service du nœud physique. Le locataire gère le projet, la configuration logicielle, les droits des certificats, les identifiants et les sauvegardes des données métier. | L’équipe gère le matériel, le système, le réseau et le projet. Elle doit aussi savoir qui intervient en cas de panne et quel nœud peut remplacer la machine. | La plateforme gère l’environnement de base. L’équipe doit s’adapter au cycle de vie des tâches, aux mises à jour des images et au modèle de permissions. En cas d’échec, il faut distinguer un problème de plateforme d’un problème de projet. |
Ce tableau compare les conditions et les responsabilités. Il ne signifie pas que tous les services partagés ont les mêmes temps d’attente ni ne garantit un temps de compilation fixe pour une configuration donnée.
Supposons qu’une même équipe utilise durablement un XR Build 24 : M4 / 24GB / 512GB. Les 20 builds quotidiens sont une hypothèse de charge, pas une promesse de performances ni l’autorisation d’exécuter 20 tâches simultanément.
Sur la base de 30 jours par mois et de 90 jours par trimestre, prévoyez 600 builds par mois et 1 800 par trimestre. Consultez vos propres journaux de pipeline pour connaître le nombre de réussites, de nouvelles tentatives et le temps passé en file d’attente.
$204.1 / mois
Adapté aux projets récemment migrés, aux chaînes d’outils encore en cours d’ajustement ou aux charges à long terme qui restent à confirmer. Commencez par valider un cycle complet d’Archive, de signature et d’export des artefacts.
À vérifier : la capacité à absorber les builds quotidiens dans la durée.
$555.2 / trimestre
Adapté aux pipelines dont l’environnement a été validé et qui devraient rester en service. Sur trois mois, le paiement trimestriel revient $57.1 moins cher que trois paiements mensuels consécutifs.
Économie : $204.1 × 3 − $555.2 = $57.1
Cette comparaison porte uniquement sur la location du nœud, sans extension de stockage ni frais de mise en parallèle Thunderbolt 5. Les seuls moyens de paiement acceptés sont USDT-TRC20 et Visa / Mastercard / Amex (via Stripe) ; tous les paiements sont en dollars. La disponibilité effective des moyens de paiement est indiquée par l’interface du serveur.
Le coût de location est indiqué dans le catalogue, mais l’attente en file et le coût des incidents sont à mesurer. Notez le délai entre l’envoi du commit et le démarrage du build, sa durée d’exécution, les causes d’échec et le temps d’intervention manuelle. Pour une machine achetée, comptabilisez aussi le déploiement initial, les mises à jour système, le nettoyage du disque et la gestion du matériel, au lieu de considérer ce temps comme nul.
Comme le nœud n’est pas virtualisé, son CPU, sa mémoire unifiée, son stockage et son environnement macOS ne sont pas partagés avec d’autres locataires. Cela limite la concurrence entre locataires, mais les tâches simultanées d’un même locataire peuvent toujours se gêner.
La compilation à froid, l’édition de liens et les simulateurs sollicitent en même temps le CPU, la mémoire et le disque. Établissez d’abord une référence avec une seule tâche, puis augmentez progressivement la concurrence. Surveillez la pression mémoire et l’utilisation du swap au lieu de déduire le nombre de tâches possibles du seul nom de la puce.
Les certificats et profils sont gérés par le locataire, et le trousseau n’est pas partagé avec d’autres locataires. Prévoyez le compte de build, le déverrouillage du trousseau et les droits sur les clés privées pour éviter que des tâches simultanées de la même équipe ne modifient les paramètres de signature en même temps.
macOS est disponible avec son interface graphique complète et en ligne de commande, et permet de basculer entre plusieurs versions de Xcode. Indiquez la version dans chaque tâche et séparez les répertoires de cache par projet. Après une mise à niveau de la chaîne d’outils, revérifiez les dépendances et les résultats de build.
Le catalogue comprend trois configurations : XR Build 16 (M4 / 16GB / 256GB), XR Build 24 (M4 / 24GB / 512GB) et XR Build Pro 64 (M4 Pro / 64GB / 2TB). Commencez par vérifier si la configuration d’entrée suffit à votre projet. Envisagez une configuration supérieure si la pression mémoire reste élevée, si la matrice de simulateurs s’élargit ou si le cache grossit. Le choix d’une machine ne permet pas de déduire un nombre universel de tâches simultanées.
La location ne remplace pas tous les équipements locaux. Avant de choisir, demandez-vous si l’équipe doit accéder physiquement aux machines, si elle dispose déjà d’une exploitation bien rodée et si sa charge restera stable dans le temps.
Si les tâches de build sont stables et que l’équipe dispose déjà du réseau, de l’alimentation, de l’accès à distance et d’un responsable matériel, l’achat mérite une évaluation complète des coûts. Intégrez dans un même budget l’achat, les frais de fonctionnement, le temps de l’équipe et le matériel de remplacement en cas de panne. Ne comparez pas seulement les prix affichés.
Pour les périphériques locaux, le débogage sur site ou les tâches qui nécessitent de manipuler directement les appareils, garder une machine sur place est plus simple. Vous pouvez déplacer la compilation et l’archivage vers le cloud, tout en réservant aux machines locales les tests qui nécessitent un accès physique. Rien n’oblige à choisir une seule solution.
Si le code source et l’environnement de build doivent rester dans l’entreprise, vérifiez d’abord les règles applicables au traitement des données et au réseau. C’est à l’équipe de décider si un nœud distant est compatible avec ses exigences ; un nœud dédié ne remplace ni les validations internes ni les règles de gestion des données.
Si vous lancez peu de builds, que les tâches sont courtes, que l’environnement peut être recréé sans état persistant et que les configurations comme les règles de file d’attente de la plateforme vous conviennent, un service partagé peut alléger la gestion de l’environnement. Vérifiez qu’il prend en charge la version de Xcode, le mode de signature et la stratégie de cache dont vous avez besoin. Ne vous fiez pas au seul argument « prêt à l’emploi » sans examiner tout le cycle de vie des tâches.
Ne tirez pas de conclusion à partir de commits, de versions de Xcode ou d’états de cache différents. Gardez les entrées identiques, puis mesurez séparément l’attente, l’exécution, les échecs et les interventions manuelles.
Utilisez le même commit, le même Scheme, la même configuration de build et la même version de Xcode. Conservez le fichier de verrouillage des dépendances, indiquez si le cache est froid ou déjà alimenté, et mesurez le temps de synchronisation du code source et des dépendances.
Partez de la récupération du code source et allez jusqu’à l’installation des dépendances, aux tests, à l’Archive, à la signature et à l’export des artefacts. Des tests réussis ne garantissent pas une publication réussie : vérifiez les artefacts finaux, la signature et les journaux de build.
Augmentez progressivement le nombre de tâches en suivant le rythme des commits de l’équipe. Mesurez l’attente en file, la pression mémoire, l’espace disque disponible et les nouvelles tentatives après échec. Vous pourrez alors déterminer si la configuration suffit ou s’il faut répartir les tâches sur plusieurs nœuds.
Organisez le renouvellement des certificats, la gestion des identifiants, le nettoyage du cache et les sauvegardes. Vérifiez les modalités de renouvellement et la gestion à l’échéance avant de choisir un paiement mensuel ou trimestriel. Un seul build réussi ne suffit pas à prouver la stabilité dans la durée.
Apportez votre projet, votre Scheme et votre processus de publication. Vérifiez d’abord que vous pouvez générer vos builds, puis choisissez la configuration, le niveau de concurrence et la durée de facturation.
Trois configurations, six nœuds. Les caractéristiques et les tarifs des quatre périodes de facturation sont détaillés sur la page des offres.