Berry M4
- Puce
- M4
- Mémoire
- 16GB
- Stockage
- 256GB
Choisir un Mac cloud selon la tâche
Confiez vos tâches de développement, de build et d’expérimentation
Confiez vos tâches de développement, de build et d’expérimentation
à un Mac physique dédié
BerryVM fournit des nœuds Mac mini physiques entièrement dédiés, et non des machines virtuelles. Installez vos dépendances, exécutez Xcode et la chaîne d’outils Swift, gérez des builds continus ou évaluez des charges MLX sur une configuration avec davantage de mémoire.
Vérifiez d’abord la compatibilité logicielle, les besoins en mémoire, la durée des tâches et le nœud cible, puis choisissez Berry M4 ou Berry M4 Pro. Les accès, identifiants de projet et éléments de signature doivent rester gérés selon les procédures de sécurité de votre équipe.
- Type de service
- Appareil entièrement dédié
- Configurations disponibles
- 2
- Nœuds disponibles
- 5
VALIDATION DE CHARGE
Validation du lot de tâches
BATCH / DEV-05
Entrées
Code, dépendances, paramètres de build
À configurer
Exécution
Xcode / Swift / Runner / MLX
Nœud dédié
Sorties
Artefacts de build, journaux, résultats d’expériences
Livraison selon le processus
Berry M4 Pro
- Puce
- M4 Pro
- Mémoire
- 64GB
- Stockage
- 2TB
Nœuds généralement disponibles à la réservation
L’état réel de disponibilité est indiqué en temps réel dans la console
Développement iOS et macOS
Transformez un Mac distant en environnement de développement reproductible
Convient aux développeurs qui ont besoin de l’interface graphique macOS complète et de la ligne de commande, souhaitent déporter la charge de leur appareil local vers un nœud distant ou doivent uniformiser les versions de la chaîne d’outils pour leur équipe.
Environnement de développement
Projets Xcode et Swift
Après avoir installé la version de Xcode, les outils en ligne de commande et les dépendances Swift requis par le projet, lancez d’abord un build propre. Placez les données dérivées, le cache des paquets et les artefacts du projet dans des répertoires clairement définis afin d’éviter les états temporaires impossibles à tracer entre branches ou chaînes d’outils.
- Vérification du projet :Vérifiez le projet, l’espace de travail, le Scheme, la version minimale du système et la cible de build.
- Vérification des dépendances :Figez les versions de Swift Package Manager, CocoaPods ou des autres outils de dépendances, ainsi que leurs fichiers de verrouillage.
- Préparation de la signature :Ne transmettez que les éléments de signature nécessaires à la tâche, limitez les droits d’accès aux fichiers et consignez la personne responsable des mises à jour.
- Méthode de collaboration :Transférez les éléments via le dépôt de code, le dépôt d’artefacts et des journaux désensibilisés ; ne remplacez pas la description des changements par un historique de discussion.
Vérifiez d’abord ces 5 points après la livraison
- Informations sur l’appareil
- Modèle, mémoire et stockage conformes à la commande
- Outils système
- Terminal, Git et réseau de base opérationnels
- Outils de développement
- Xcode conforme à la version requise par le projet
- Organisation du disque
- Code source, cache et artefacts enregistrés dans des répertoires distincts
- Session distante
- Affichage, clavier et reprise après déconnexion conformes aux attentes
Build CI/CD
Concevez les nœuds de build autour des files d’attente, du cache et des journaux
Un build continu ne se résume pas à installer un Runner. La stabilité et la réutilisabilité d’un nœud dépendent de l’isolation des tâches, de la stratégie d’invalidation du cache, de la conservation des journaux et de la méthode d’extension de la concurrence.
CONTRÔLE DU RUNNER
Lot de build / IOS-RELEASE
Nœud prêt
FILE
Contrôlez le nombre de tâches exécutées simultanément
D’abord en série
Commencez par une seule file et mesurez l’évolution du CPU, de la mémoire, du disque et de la durée des builds. Pour paralléliser, ajoutez des appareils dédiés plutôt que d’empiler aveuglément les tâches sur un même nœud.
CACHE
Rendez le cache identifiable et invalidable
Nettoyage ciblé
La clé de cache doit au minimum inclure la version de la chaîne d’outils, le fichier de verrouillage des dépendances et la plateforme cible. Si le taux d’utilisation baisse ou qu’une dépendance pose problème, identifiez et nettoyez le lot concerné au lieu d’effacer tout l’appareil.
JOURNAUX
Conservez des journaux suffisants pour reproduire le problème
D’abord désensibiliser
Enregistrez l’identifiant de tâche, la version du commit, la version de la chaîne d’outils, l’heure de début, l’état final et l’étape d’échec. Retirez les jetons, clés et champs sensibles du projet avant l’envoi.
EXTENSION
Étendez la concurrence avec des appareils
Étendre par nœud
Lorsque l’attente dans la file devient un goulot d’étranglement, ajoutez des nœuds dédiés pour accueillir de nouveaux Runners. Attribuez à chaque appareil des étiquettes et un répertoire de travail distincts afin d’éviter une exécution dans le mauvais environnement.
Build React Native
Vérifiez séparément JavaScript et la chaîne de build native
Un build React Native dépend à la fois des paquets JavaScript, des modules natifs, du projet Xcode et de la configuration de signature. Un diagnostic par couche permet de localiser les problèmes plus efficacement qu’une réinstallation répétée de l’environnement.
Figez les sources et les points d’entrée des dépendances
Vérifiez Node.js, le gestionnaire de paquets, les fichiers de verrouillage et le mode d’accès aux dépendances privées. Avant l’installation, assurez-vous que le répertoire de travail est propre afin que des modules résiduels locaux ne soient pas pris pour des dépendances reproductibles.
- Consignez les versions de Node.js et du gestionnaire de paquets
- Utilisez le fichier de verrouillage des dépendances validé
- Limitez la portée de lecture des identifiants des dépôts privés
Vérifiez les modules natifs
Vérifiez la compatibilité des Pods, paquets Swift et modules natifs personnalisés avec la version cible de Xcode. Après une mise à jour des dépendances, validez séparément les couches JavaScript et native afin de ne pas mélanger les deux types d’erreurs dans un même build.
- Vérifiez la cible de déploiement iOS
- Contrôlez les paramètres de compilation des modules natifs
- Consignez la sortie de l’installation des dépendances
Exécutez le build Xcode
Utilisez un projet, un Scheme, une Configuration et des paramètres d’exportation clairement définis. Associez les journaux de build et le répertoire des artefacts au même identifiant de tâche pour pouvoir retrouver précisément l’étape concernée en cas d’échec.
- Séparez les configurations de débogage et de publication
- Conservez les journaux désensibilisés de l’étape d’échec
- Vérifiez l’intégrité des artefacts
Livrez les artefacts et les informations de suivi
Téléversez les artefacts de build dans l’emplacement approuvé par l’équipe, avec la version du commit, la version de la chaîne d’outils et le résultat du build. N’intégrez pas d’identifiants longue durée dans les artefacts ou les journaux ordinaires.
- Générez des noms d’artefacts traçables
- Associez la version du commit et le lot de build
- Nettoyez les fichiers intermédiaires selon les règles internes
MLX et expériences d’IA
Calculez d’abord les besoins en mémoire, puis choisissez la configuration haute mémoire
La configuration haute mémoire offre un M4 Pro, 64GB de mémoire et 2TB de stockage. Elle convient mieux à l’évaluation de l’inférence locale, du chargement de modèles et des expériences exigeant davantage de mémoire, mais son adéquation dépend toujours du modèle, de la précision, de la longueur du contexte et du mode de concurrence.
Tâches haute mémoire
Tâches à évaluer en priorité avec Berry M4 Pro
Validation du chargement du modèle
Vérifiez le format du modèle, la méthode de quantification, les versions des dépendances et la consommation réelle de mémoire.
Expériences d’inférence locale
Consignez les entrées, la longueur du contexte, les paramètres de lot et les résultats afin de créer une expérience reproductible.
Prétraitement des données
Séparez les données sources, les fichiers intermédiaires et le cache des modèles afin d’éviter de saturer le disque avec des fichiers temporaires invisibles.
Comparaison de paramètres en plusieurs passes
Ne modifiez qu’une variable clairement définie par passe et consignez la mémoire maximale, l’état d’achèvement et les anomalies.
Ne remplacez pas le calcul de capacité par le choix d’un modèle
Validez d’abord la chaîne d’exécution sur un petit échantillon, puis déterminez la durée de location selon la mémoire maximale et l’espace disque réellement utilisés. Les fichiers de modèles, jeux de données, caches et résultats doivent tous entrer dans le calcul de capacité.
- Paramètres du modèle
- Consignez la version, le format et la méthode de quantification
- Contexte d’exécution
- Vérifiez la longueur, la taille des lots et la concurrence
- Mémoire maximale
- Basez-vous sur un échantillonnage de la tâche réelle
- Capacité disque
- Calculez ensemble modèles, données et cache
- Livraison des résultats
- Planifiez à l’avance l’exportation et le nettoyage
Préparation au débogage à distance
Le Mac cloud et les appareils de test externes ont chacun leur périmètre
Le Mac cloud peut exécuter les outils de développement, compiler les projets et recueillir les journaux côté hôte. La connexion aux appareils externes, leur accessibilité réseau et les opérations côté appareil restent sous la responsabilité de votre environnement de test.
Chemin réseau
Commencez par prouver que les deux extrémités communiquent de manière stable
Consignez le nœud cloud, le réseau où se trouvent les appareils externes, les ports nécessaires et le sens des connexions. Testez d’abord la connectivité de base et la stabilité de la session, puis passez au débogage applicatif.
Identifiants et signatures
Ne livrez que les autorisations nécessaires à la tâche
Isolez les clés, jetons et éléments de signature par projet, limitez leur portée de lecture et définissez les responsabilités de mise à jour. N’inscrivez pas d’identifiants dans le dépôt de code, la sortie des scripts de build ou les demandes d’assistance ordinaires.
Sécurité des journaux
Conservez le contexte, pas les secrets
Les journaux doivent inclure l’identifiant de tâche, l’heure, les étapes de reproduction et l’étape d’erreur. Avant de les transmettre à l’assistance, retirez les identifiants d’accès, adresses privées, données utilisateur et contenus sans rapport avec le projet.
Correspondance entre scénarios et configurations
Choisissez selon la mémoire, le disque et la durée des tâches
Les deux configurations sont des nœuds Mac mini physiques entièrement dédiés. Évaluez d’abord Berry M4 pour les builds légers et le développement quotidien ; privilégiez Berry M4 Pro pour les expériences haute mémoire, l’inférence locale et les jeux de travail plus importants.
| Charge de travail | À évaluer en priorité | Caractéristiques disponibles | Pourquoi choisir cette configuration | À vérifier avant la commande |
|---|---|---|---|---|
| Développement Swift quotidien et maintenance de projet | Berry M4 | M4 / 16GB / 256GB | Convient à l’initialisation de la chaîne d’outils, à l’édition du code, aux compilations courantes et aux validations sur une seule tâche. | Taille du projet, cache des dépendances et espace occupé par les données dérivées. |
| Builds iOS et macOS légers | Berry M4 | M4 / 16GB / 256GB | Permet d’établir d’abord un pipeline reproductible, puis d’ajouter des nœuds dédiés selon la pression de la file. | Mémoire maximale, stratégie de cache et longueur de la file de build. |
| Build React Native dans le cloud | Berry M4 | M4 / 16GB / 256GB | Convient à la vérification des dépendances JavaScript, des modules natifs et de la chaîne de build Xcode. | Nombre de modules natifs, taille des artefacts et nombre de tâches parallèles. |
| Espace de travail Xcode haute mémoire | Berry M4 Pro | M4 Pro / 64GB / 2TB | Davantage de mémoire et de stockage pour les jeux de travail, caches et répertoires d’artefacts volumineux. | Mémoire maximale réelle, croissance du disque et durée de location. |
| Inférence locale et expériences MLX | Berry M4 Pro | M4 Pro / 64GB / 2TB | À privilégier pour le chargement de modèles, les besoins mémoire élevés et le suivi d’expériences en plusieurs passes. | Format du modèle, méthode de quantification, longueur du contexte et mémoire maximale. |
Périmètre clair et jeu de travail léger
Convient au développement quotidien, aux builds légers, à la migration des dépendances et à un Runner à file unique. Si la mémoire ou le disque devient régulièrement un goulot d’étranglement, passez à une configuration supérieure.
Besoins mémoire plus élevés et jeu de travail plus important
Convient aux grands espaces de travail Xcode, aux expériences MLX, à l’inférence locale et aux répertoires de cache volumineux. Validez toutefois la capacité selon le modèle et les paramètres réels de la tâche.
Dernières vérifications avant de commencer
Configuration, durée, nœud et chemin des données : tout est confirmé ?
Choisissez la durée réellement nécessaire : jour, semaine, mois ou trimestre. Avant de commander, vérifiez Berry M4 ou Berry M4 Pro, les nœuds candidats, le stockage supplémentaire, la mémoire maximale de la tâche et le mode de livraison des artefacts de build et des données d’expérience.