Évaluez la durée de chaque Archive, le volume des dépendances, le taux de cache et l’espace disque temporaire utilisé.
Évaluez vos besoins avant de choisir vos ressources
Un Mac cloud dédié pour quels types de charge de travail ?
La seule configuration actuellement proposée est CDNMac M4 : puce M4, 16 Go de RAM et SSD de 256 Go. Chaque commande comprend une machine physique dédiée, et non une machine virtuelle. Évaluez vos files d’attente, votre stockage, vos besoins d’interaction à distance et votre utilisation mémoire avant de choisir la durée, le nœud et les options.
Évaluez la fréquence d’utilisation de SSH et VNC, la synchronisation du code, les tâches en arrière-plan et l’espace de travail requis.
Évaluez les builds de branches en parallèle, l’isolation des files, la vérification de signature, la collecte des journaux et la durée de conservation des artefacts.
Vérifiez d’abord que les poids du modèle, le cache de contexte et les jeux de données tiennent dans les 16 Go de mémoire unifiée.
FICHE DE CHARGE
Fiche d’adéquation des tâches
Configuration disponible
CDNMac M4
- Puce
- M4
- Mémoire
- 16 Go
- Disque système
- SSD 256 Go
- Type de ressource
- Machine physique dédiée
File de build
Adaptée à l’exécution séquentielle ou aux files contrôlées
Interface graphique
macOS avec interface graphique et ligne de commande
Extension de stockage
SSD 1 To ou 2 To en option
Appareils en parallèle
Connexion Thunderbolt 5 à évaluer
La disponibilité, les nœuds et les options sont indiqués en temps réel dans la console
1 COMMANDE = 1 MAC PHYSIQUE
Ferme de build iOS
Configurez CDNMac M4 comme exécuteur de build dédié
Convient aux équipes qui utilisent déjà GitHub Actions, GitLab CI, Jenkins ou leur propre système d’orchestration. Enregistré comme self-hosted runner, le Mac cloud reçoit les événements du dépôt ; CDNMac M4 restaure les dépendances, lance les tests et Xcode Archive, vérifie les signatures et produit les artefacts de build.
Une machine physique dédiée signifie que le processeur, la mémoire, le disque et le répertoire de travail ne sont pas partagés avec d’autres clients. Elle convient aux pipelines qui exigent une version précise de Xcode, un répertoire de cache stable et un espace de travail traçable, mais ne résout pas automatiquement les conflits de dépendances ni les problèmes de signature propres au projet.
Conseil : un répertoire de travail par dépôt
Jetons : limitez les autorisations au strict nécessaire
Nettoyage : à la fin de chaque tâche
Ordre d’exécution du build
RUNNER / M4
-
01
Recevoir les événements du dépôt
Placez les tâches dans une file contrôlée, selon la branche principale, une branche de publication ou un déclenchement manuel.
-
02
Restaurer les dépendances verrouillées
Utilisez en priorité les fichiers de verrouillage et les caches vérifiables pour éviter les dérives de l’environnement.
-
03
Exécuter Archive
Fixez les versions de Xcode, Scheme et Configuration, ainsi que les paramètres d’exportation.
-
04
Vérifier et transmettre les artefacts
Conservez les journaux nécessaires et copiez les artefacts vers un espace de stockage contrôlé par l’équipe.
Build automatisé d’apps
Gérez séparément les déclenchements, le cache, les échecs et la conservation des artefacts
Automatiser un build ne consiste pas à exécuter à distance une commande locale. Chaque exécution doit être reproductible, les échecs faciles à diagnostiquer et les fichiers résiduels supprimés, sans jamais verser les éléments de signature sensibles dans le dépôt.
Orientez chaque branche vers une file dédiée
La branche principale peut lancer les vérifications continues, les branches de publication l’Archive et l’export, et les branches de correction des builds à la demande. Définissez des règles de concurrence distinctes pour éviter que plusieurs espaces de travail modifient le même cache ou DerivedData.
Le fichier de verrouillage doit permettre de vérifier le cache
Gérez séparément les caches de Swift Package Manager, CocoaPods, Flutter et des dépendances JavaScript. La clé de cache doit inclure l’empreinte du fichier de verrouillage, la version des outils et l’architecture. En cas d’échec, relancez une installation propre.
Gardez une chronologie utile à la reproduction des problèmes
Consignez l’heure de début, l’identifiant du commit, la version de Xcode, l’étape en échec et le code de sortie. Avant tout envoi, retirez les jetons, clés privées, mots de passe de certificat et autres données sensibles.
Définissez qui les conserve, pendant combien de temps et quand les supprimer
Copiez les archives, fichiers de symboles et paquets exportés vers un stockage contrôlé, puis supprimez les fichiers temporaires locaux selon les règles de l’équipe. Ne prenez pas le répertoire de travail du Mac cloud pour votre seule sauvegarde.
Développement macOS à distance
Utilisez SSH pour la ligne de commande et VNC pour les tâches graphiques
SSH convient aux opérations Git, à l’installation de dépendances, aux commandes de build, à la consultation des journaux et aux tâches en arrière-plan. VNC est préférable pour l’interface graphique macOS, les réglages de projet Xcode ou le débogage visuel. Utilisez des identifiants distincts et des autorisations minimales pour chaque accès ; ne stockez pas d’identifiants persistants dans le dépôt.
Synchronisez le code via le dépôt, un transfert de fichiers contrôlé ou le processus déjà utilisé par l’équipe. Pour les tâches de longue durée, consignez le processus, le répertoire de travail et l’emplacement des résultats afin de pouvoir vérifier leur état après la fermeture de la session. Avant la fin de la location, exportez les modifications, journaux de build, archives et autres artefacts nécessaires.
Liste de contrôle pour une session à distance
SESSION DE DÉV
SSH
Commandes, Git et tâches en arrière-plan
Idéal pour les tâches scriptables, avec un historique des commandes et des codes de sortie faciles à conserver.
VNC
Xcode et interface graphique
Ouvrez une session uniquement pour les opérations graphiques et déconnectez-vous dès qu’elles sont terminées.
SYNCHRO
Transfert du code et des artefacts
Validez les modifications et copiez les archives et journaux vers un stockage contrôlé.
FIN
Nettoyer avant la fin de la location
Exportez les éléments nécessaires, supprimez les identifiants temporaires et vérifiez qu’aucune modification ne reste à synchroniser.
Développement mobile multiplateforme
Flutter et React Native doivent toujours passer par la chaîne de build Xcode
Les frameworks multiplateformes permettent de partager le code métier, mais les builds iOS dépendent toujours de macOS, de Xcode, des dépendances natives et de l’environnement de signature. Évaluez séparément la couche du framework et celle du build natif.
Flutter pour iOS
Évaluez séparément Dart, CocoaPods et les étapes Xcode
Restaurez d’abord les dépendances Dart, gérez ensuite CocoaPods et les plugins natifs, puis lancez la compilation et l’export Xcode. Distinguez les caches du SDK Flutter, des fichiers de verrouillage des plugins, de Pods et de DerivedData ; une même clé ne doit pas couvrir toutes les étapes.
- Verrouillez les versions de Flutter, Ruby, CocoaPods et Xcode.
- En cas de cache manquant, prévoyez une installation propre.
- Précisez dans les journaux si l’échec vient du framework ou de la couche native.
React Native pour iOS
Verrouillez ensemble les dépendances JavaScript et le projet natif
Le gestionnaire de paquets Node.js gère les dépendances JavaScript ; CocoaPods et Xcode prennent en charge la partie native iOS. Verrouillez à la fois la version du gestionnaire, les fichiers de dépendances, l’état de Pods et les paramètres de build pour obtenir des résultats cohérents en local et à distance.
- Utilisez un répertoire de travail et un node_modules distincts pour chaque dépôt.
- Après une mise à jour des modules natifs, revérifiez Pods et les réglages Xcode.
- Stockez les éléments de signature dans un emplacement contrôlé, jamais dans le dépôt.
Tests d’IA sur Apple Silicon
Idéal pour vérifier la compatibilité des modèles et tester des prototypes
CDNMac M4 permet de vérifier la compatibilité des frameworks d’inférence avec Apple Silicon, de tester la conversion de modèles, d’exécuter de petits jeux d’échantillons et de valider l’intégration à une application. Il ne garantit pas un débit donné pour n’importe quel modèle et ne convient pas à l’inférence en production sur de grands modèles sans vérification préalable des besoins mémoire.
La configuration actuelle comprend 16 Go de RAM. Pour évaluer vos besoins, prenez en compte les poids du modèle, la mémoire d’exécution, le cache de contexte, les données d’entrée, les outils de développement et le système. La taille du fichier du modèle, à elle seule, ne permet généralement pas de savoir si la tâche fonctionnera de façon stable.
Budget mémoire avant exécution
16 GO AU TOTAL
- Poids du modèle
- Vérifiez la mémoire réellement utilisée après chargement, pas seulement la taille du fichier téléchargé.
- Cache de contexte
- Plus la longueur du contexte augmente, plus l’espace occupé par le cache peut croître.
- Environnement d’exécution et outils
- Prévoyez de l’espace pour le framework, les outils de conversion, l’IDE et le système.
- Entrées et résultats
- Pour les grands jeux de données, évaluez un SSD de 2 To et procédez par lots.
Adapté à
Vérifications de compatibilité, prototypes et petits jeux d’échantillons
Comparer les configurations
Commencez par la configuration de base et n’ajoutez que les options nécessaires
Nous ne créons pas de modèles fictifs pour couvrir chaque usage. Tous les cas partent de CDNMac M4, avec des options fixes pour étendre le stockage ou connecter des appareils en parallèle.
Seule configuration proposée
6 nœuds au choix
CDNMac M4
Mac mini M4 · 16 Go de RAM · SSD 256 Go
-
01
Builds légers Vérification d’un dépôt, file courte, Archive standardConfiguration de base CDNMac M4
Commencez avec le SSD de 256 Go pour vérifier que dépendances, caches et artefacts peuvent être gérés de façon fiable avec votre stratégie de nettoyage.
-
02
Développement au quotidien Espaces de travail durables, plusieurs projets, usage fréquent de l’interface graphiqueCDNMac M4 + SSD 1 To en option
Adapté aux workflows qui nécessitent de conserver davantage de dépôts, de SDK, de caches de dépendances et d’archives de build.
-
03
Grands jeux de données ou tests de modèles Fichiers de modèles, échantillons, résultats de conversion et sorties par lotsCDNMac M4 + SSD 2 To en option
Cette option augmente le stockage, pas les 16 Go de RAM. Vérifiez séparément vos besoins mémoire avant de commander.
-
04
Workflow avec appareils en parallèle Pour les workflows qui nécessitent une connexion rapide entre plusieurs appareilsÉvaluez la connexion Thunderbolt 5
Choisissez l’option de connexion pour chaque appareil et vérifiez d’abord la topologie des tâches, le sens des transferts et la compatibilité logicielle.
| Type de tâche | Configuration de base | Options à évaluer | À vérifier avant de commander |
|---|---|---|---|
| Build iOS léger | CDNMac M4 | SSD 256 Go de base | Volume des dépendances, nettoyage du cache, taille de chaque artefact |
| Développement à distance au quotidien | CDNMac M4 | SSD 1 To selon vos besoins de capacité | Nombre de dépôts, SDK, archives et espace de travail total |
| Tests de données ou de modèles | CDNMac M4 | SSD 2 To selon vos besoins de capacité | Les 16 Go de RAM suffisent-ils pour le modèle, le cache et l’environnement d’exécution ? |
| Workflow avec appareils en parallèle | CDNMac M4 | Connexion Thunderbolt 5 | Nombre d’appareils, topologie de connexion et compatibilité de la chaîne d’outils |
Vérifiez d’abord les cas qui ne conviennent pas
Si vous avez besoin d’un matériel hors catalogue, la configuration de base ne le remplacera pas
Si votre projet exige une puce non proposée, plus de 16 Go de mémoire ou une autre capacité de stockage interne, ne considérez pas CDNMac M4 comme répondant déjà à ces besoins. Communiquez à l’équipe votre configuration requise, vos versions d’outils, le volume de données et votre mode d’exécution parallèle pour confirmation.
Seule la puce M4 est proposée ; aucune autre configuration de puce n’est disponible.
La configuration comprend 16 Go de RAM ; les options de stockage ne remplacent pas la mémoire.
Le disque système de base est un SSD de 256 Go ; choisissez une option fixe pour augmenter la capacité.
Évaluez d’abord les files, l’isolation des tâches et une configuration avec plusieurs commandes. Ne supposez pas qu’une seule machine permet un parallélisme illimité.
Étapes suivantes
Poursuivez selon votre niveau de préparation
Vérifiez d’abord la configuration proposée, puis comparez les six nœuds. Avant de commander, suivez le guide pour configurer la connexion et valider l’environnement.
Voir les offres et les options
Vérifiez les quatre durées de location de CDNMac M4. Les options SSD de 1 To et 2 To, ainsi que la connexion Thunderbolt 5, sont facturées séparément.
Voir les offresComparer les six nœuds disponibles
Découvrez comment choisir parmi Singapour, Tokyo, Séoul, Hong Kong, l’est des États-Unis et l’ouest des États-Unis.
Comparer les nœudsPréparer une première connexion sécurisée
Avant de commander, préparez les accès au code, le mode de connexion, l’environnement de build et l’emplacement d’export des artefacts.
Lire le guide de connexionConfigurer et commander
Choisissez la durée, le nœud et les options. La disponibilité et les informations de livraison sont affichées en temps réel dans la console.
Configurer ma commandeVous avez confirmé que CDNMac M4 convient à vos tâches ?
Choisissez la durée, l’un des six nœuds et les options nécessaires pour commander. En cas de doute sur la mémoire, la puce ou le stockage, contactez d’abord l’équipe.