Des ressources de build adaptées à votre équipe

Choisissez un nœud selon votre pipeline

De la CI quotidienne d’une seule app aux builds Unity, deux configurations au choix.

Commencez par déterminer si vos tâches tournent tous les jours ou se concentrent au moment des sorties, puis évaluez vos besoins en mémoire, en cache et en exécutions parallèles. VMFly met à votre disposition un Mac mini Apple Silicon physique, entièrement dédié et non virtualisé. Chaque nœud est réservé à un seul client : aucune concurrence avec d’autres locataires sur la même machine.

Louer un nœud dédié Comparer les 2 offres
  • À partir de $20.1/jour
  • Puce Apple Silicon M4 / M4 Pro
  • Facturation Jour / semaine / mois / trimestre
Builds quotidiens · Nœud longue durée

Remplacez la file partagée par votre propre runner

Pour un pipeline dédié à une seule app qui tourne tous les jours, commencez avec un nœud Glide M4 en abonnement mensuel : Apple Silicon M4, 16GB de mémoire et SSD de 256GB, à $100.7/mois. Dirigez les tâches macOS de GitHub Actions vers votre runner pour ne plus attendre la fin des tâches d’autres clients sur une machine partagée.

Migrez d’abord un workflow reproductible

Choisissez un pipeline de build qui produit déjà des résultats fiables. Notez le commit, la version de Xcode, le fichier de verrouillage des dépendances et la méthode de signature. Effectuez un build propre avant d’activer le cache, afin d’éviter que d’anciens fichiers ne masquent des différences d’environnement.

  1. Installez et enregistrez le runner self-hosted de votre équipe sur le nœud.
  2. Attribuez au runner un label propre au projet, par exemple vmfly-ios, et limitez les dépôts autorisés à l’utiliser.
  3. Lancez l’ancien pipeline et le nouveau nœud avec le même commit, puis comparez les tests, la configuration d’archivage et les artefacts.

Idéal pour les vérifications sur une branche donnée, les builds nocturnes et les tests de régression quotidiens.

Ressources dédiées ne veut pas dire parallélisme illimité

Une machine réservée élimine la concurrence avec d’autres clients, mais votre équipe doit toujours organiser ses propres tâches. Évitez de lancer tous les jobs simultanément sur une seule machine dès le premier jour de la migration.

  • Commencez par une tâche et surveillez la mémoire utilisée au pic de compilation, l’espace disque disponible et la croissance du cache.
  • Attribuez des labels distincts aux tâches d’archivage et aux tests UI pour éviter les écritures simultanées dans le même répertoire de travail.
  • Vérifiez sur votre projet si 16GB de mémoire suffisent avant d’ajouter un nœud ou de choisir une autre configuration.
Louer le Glide M4

La validation ne se résume pas à un statut vert : vérifiez aussi que l’équipe peut télécharger les artefacts, que les journaux sont conservés et que le runner redémarre correctement après un redémarrage de la machine. L’abonnement mensuel convient à un usage régulier, mais tous les projets n’ont pas besoin d’une machine allumée tout le mois.

Pics de versions · Location à la journée

Séparez les tâches d’archivage et les tests UI

Les goulots d’étranglement se concentrent souvent sur quelques jours pendant la semaine de sortie. Ajoutez un Cruise M4 Pro à la journée pour $61.5/jour, avec Apple Silicon M4 Pro, 64GB de mémoire et un SSD de 2TB pour les tests UI ou l’archivage. Votre nœud habituel continue les vérifications quotidiennes, sans investissement matériel à long terme pour absorber un pic temporaire.

Définissez les rôles avant d’augmenter la capacité

Une machine pour l’archivage et une autre pour les tests : les ressources sont ainsi clairement réparties. Ajouter des runners sans séparer les tâches, qui attendent toujours la même étape séquentielle, ne raccourcira pas automatiquement le pipeline de sortie.

  • Utilisez le même commit pour générer séparément les tâches d’archivage et de test.
  • Définissez le nom et l’emplacement de téléversement des artefacts pour éviter que des branches différentes ne s’écrasent mutuellement.
  • Consignez les étapes de préparation de l’environnement pour pouvoir recréer le nœud temporaire à partir des fichiers de configuration.

Mesurez d’abord le chemin critique, puis augmentez le parallélisme. Aucun gain de vitesse n’est garanti sans mesures.

Préparez la restitution avant la fin de la sortie

Définissez dans la checklist de sortie les conditions de fin d’utilisation du nœud temporaire : dernière validation terminée, artefacts récupérés et journaux de diagnostic enregistrés. Vous pourrez alors mettre fin à la location. Arrêter le runner ne met pas automatiquement fin à la facturation : vérifiez l’état de l’abonnement et la date d’échéance dans le portail.

  • Exportez les archives, rapports de test et journaux d’erreur à conserver.
  • Désenregistrez le runner temporaire de votre plateforme de gestion de code.
  • Révoquez les jetons temporaires et sauvegardez les données avant l’échéance.
Louer le Cruise M4 Pro
Unity pour iOS · Export et archivage

Intégrez l’export du projet jusqu’à l’IPA dans un seul pipeline

L’export Unity vers Xcode, l’installation des dépendances, la signature et l’archivage de l’IPA doivent s’effectuer dans un environnement cohérent et traçable. Les 64GB de mémoire et le SSD de 2TB du Cruise M4 Pro offrent de la marge pour les grands projets, l’import des ressources et le cache de build. Vérifiez toutefois la capacité nécessaire et le niveau de parallélisme avec votre projet.

  1. 01

    Figez l’environnement d’export

    Notez la version de l’éditeur Unity, les dépendances du projet et les paramètres d’export iOS. Générez le projet Xcode à partir d’un commit précis pour éviter tout écart de version de l’éditeur entre votre poste et le nœud.

  2. 02

    Vérifiez la signature et l’archivage

    Contrôlez la cible, la configuration de build, le profil de provisionnement et la méthode d’export. Fournissez les éléments de signature à la tâche selon la procédure de gestion des identifiants approuvée par votre équipe ; ne les stockez pas dans le dépôt de code et ne les exposez pas dans les journaux.

  3. 03

    Séparez cache et livrables

    Le cache peut être recréé, mais les livrables de publication doivent être conservés. Définissez des répertoires et des règles de nettoyage distincts pour les fichiers intermédiaires Unity, DerivedData et les anciennes archives afin d’éviter de saturer le disque système.

Tâches interactives · Testez avant de vous engager

Le débogage a besoin d’un bureau, les tests d’un environnement reproductible

Le service ne se limite pas aux builds sans intervention. Connectez-vous au portail pour ouvrir le bureau macOS du nœud dans votre navigateur et déboguer directement avec Xcode. Vous pouvez aussi exécuter des scripts en SSH et tester des workflows d’inférence locale de modèles sur Apple Silicon.

Pour le développement à distance, testez la latence

Quand vous utilisez souvent le simulateur, vérifiez l’interface ou avancez pas à pas dans le débogueur, la latence réseau se fait davantage sentir que pendant un build en arrière-plan. Choisissez parmi Singapour, le Japon (Tokyo), la Corée du Sud (Séoul) et Hong Kong. Testez d’abord le nœud le plus proche de votre équipe avant de choisir un emplacement pour le long terme.

  • Depuis votre réseau de travail, vérifiez la lisibilité du texte, la réactivité et le transfert de fichiers.
  • Évitez de lancer les modifications quotidiennes en même temps que les longues tâches d’archivage pour limiter la concurrence au sein de l’équipe.
  • Si plusieurs personnes utilisent le même nœud, définissez au préalable des règles pour l’accès au bureau et la gestion des identifiants.

Le bureau dans le navigateur sert aux interactions, SSH à l’automatisation. Les deux peuvent être utilisés pour un même projet.

Pour les essais IA, vérifiez la mémoire nécessaire

Choisissez une configuration selon les fichiers du modèle, la précision d’inférence, la longueur du contexte et les outils exécutés simultanément, plutôt qu’en fonction du seul nom du modèle. Commencez par une courte période pour installer l’environnement et valider un exemple, puis choisissez entre le Glide M4 et le Cruise M4 Pro.

  • Vérifiez la compatibilité des dépendances avec Apple Silicon et consignez leurs versions ainsi que les paramètres de lancement.
  • Surveillez la pression mémoire en conditions réelles ; la capacité du SSD ne remplace pas celle de la mémoire.
  • Conservez les entrées, les paramètres et les sorties pour pouvoir reproduire l’expérience sur un nouveau nœud.

64GB de mémoire ne garantissent pas l’exécution de tous les modèles : la compatibilité et la capacité doivent être vérifiées avec vos tâches réelles.

Vérifications du pipeline · De la signature à la distribution

Gardez une trace exploitable de chaque étape du build

L’extrait ci-dessous illustre un workflow fastlane ; il ne s’agit pas de résultats mesurés sur un nœud. Votre équipe doit configurer les droits d’accès au dépôt de signatures, le scheme du projet, l’identifiant de l’app et les identifiants de distribution. Vérifiez chaque étape séparément avant de les intégrer à une tâche automatisée.

cruise-m4pro — fastlane
$ bundle exec fastlane match appstore --readonly
[match] Fetching signing certificates and profiles
[match] Installing signing assets into the build keychain
[match] Signing assets are ready

$ bundle exec fastlane gym --scheme "$SCHEME" --export_method app-store
[gym] Archiving the selected scheme
[gym] Exporting the archive
[gym] IPA export completed

$ bundle exec fastlane pilot upload --ipa "$IPA_PATH"
[pilot] Uploading the selected IPA
[pilot] Upload completed; processing continues on TestFlight

match : récupérez uniquement les identifiants nécessaires

La CI récupère les éléments de signature existants en lecture seule. Si l’accès au dépôt de signatures échoue, vérifiez d’abord les autorisations. N’affichez jamais de clé privée, de jeton ou de mot de passe de déchiffrement dans les journaux.

gym : distinguez archivage et export

Un archivage réussi ne garantit pas l’export de l’IPA. Conservez les journaux d’archivage et vérifiez séparément le scheme, la configuration de signature et les paramètres d’export pour identifier précisément l’étape en échec.

pilot : le téléversement n’est pas la fin du traitement

Après le téléversement, la plateforme de distribution doit encore traiter le fichier. Conservez le résultat de l’envoi et vérifiez son état de traitement : un téléversement réussi ne signifie pas que l’équipe a validé le livrable.

20 builds par jour · Comparatif des modes de déploiement

Comparez la répartition des ressources et les responsabilités d’exploitation

Prenons l’exemple d’une petite ou moyenne équipe qui lance 20 builds par jour. Ce chiffre illustre la fréquence des tâches : il ne s’agit pas d’un test de performance et il ne permet pas, à lui seul, de déterminer le nombre de machines nécessaires. Notez aussi la durée de chaque build, le volume d’exécutions simultanées, le taux de cache et les pics de sortie avant de comparer les trois options ci-dessous.

Choix de déploiement pour un même pipeline iOS ; vérifiez les fonctionnalités et les conditions de service auprès de la plateforme concernée.
Critère Nœud physique VMFly en location Achat d’un Mac Machine virtuelle partagée
Coûts Location à la journée, à la semaine, au mois ou au trimestre. Le Glide M4 coûte $100.7/mois ; les options sont facturées en supplément. Achat initial, auquel s’ajoutent l’hébergement, le réseau, l’électricité et la gestion au quotidien. Facturation selon la période ou l’utilisation de la plateforme ; vérifiez aussi les règles de file d’attente et les quotas de parallélisme.
Mise à disposition La machine physique est attribuée après confirmation du paiement. Son état de disponibilité réel est indiqué dans le portail. Il faut effectuer l’achat, attendre la livraison, connecter la machine au réseau et configurer l’accès à distance. L’attribution dépend de la planification des ressources de la plateforme. Les files d’attente et la persistance de l’environnement varient selon le service.
Exclusivité Un Mac mini entier est réservé à un seul client ; il n’est pas virtualisé. Le matériel est réservé à l’équipe, qui gère également son installation et son système. Les ressources de l’hôte sont généralement partagées avec d’autres instances ; la plateforme assure l’isolation et la répartition des ressources.
Souplesse d’évolution Changez de configuration ou ajoutez un nœud. La migration de l’environnement et des données reste à organiser par vos soins. L’augmentation de capacité nécessite généralement l’achat et le déploiement de matériel supplémentaire ; les machines existantes continuent de mobiliser votre budget d’équipement. Les configurations disponibles et les possibilités d’évolution dépendent du catalogue et des règles de planification de la plateforme.

Validez votre choix avec un même commit

20 builds courts par jour peuvent surtout nécessiter un cache stable ; quelques longs tests UI peuvent plutôt gagner à être répartis sur plusieurs nœuds. Ne changez pas de configuration en vous fondant uniquement sur le nombre de builds. Comparez la durée, la mémoire et l’espace disque utilisés par un même projet pour décider de garder un Glide M4 toute l’année ou d’ajouter un Cruise M4 Pro au moment des sorties.

VMFly fournit un nœud physique dédié. Votre équipe reste responsable des dépendances du projet, des droits du runner, des éléments de signature et de la sauvegarde des livrables. Si vous avez besoin d’une orchestration de pipeline entièrement gérée, vérifiez d’abord si vos outils actuels prennent déjà ces tâches en charge.

Choisissez selon vos besoins

Pour les builds quotidiens, tenez compte de la charge continue ; pour les pics temporaires, de la durée d’utilisation. Comparez les deux configurations et les quatre périodes de facturation avant de choisir un nœud pour votre pipeline.

Voir les 2 offres Louer un nœud dédié