Adapté au packaging léger d’un projet, aux tests unitaires et aux archives à faible concurrence. Nettoyez régulièrement le cache des dépendances pour éviter de saturer le stockage local.
Louer ZoneMini M4 Core
Intégration au pipeline d’ingénierie
Confiez vos tâches d’ingénierie post-commit à un Mac dans le cloud
ZoneMini fournit un Mac physique dédié dans le cloud, disponible en continu, et non une machine virtuelle. Confiez vos commits à un nœud fixe, puis récupérez rapports de test, archives, résultats de modèles ou fichiers média dans votre chaîne de livraison existante.
- Mode de mise à disposition
- Une commande correspond au nœud physique dédié sélectionné
- Catalogue
- 3 configurations, 5 nœuds disponibles
- Accès pris en charge
- SSH, interface graphique macOS et CI Runner
BUILD ROUTE
Exécution sur nœud fixe
-
01Commit du code Événement du dépôt, tâche planifiée ou déclenchement manuel mis en file d’attenteINPUT
-
02Exécution du build Restauration des dépendances, tests, signature et création de l’archiveRUN
-
03Livraison des artefacts Retour de l’IPA, des journaux, rapports, métriques du modèle ou fichiers médiaOUTPUT
Du déclenchement du dépôt à la vérification de l’IPA, en six étapes reproductibles
Un build iOS cloud fiable ne se résume pas à une commande Archive. Il faut une chaîne d’outils figée, des caches maîtrisés, des droits de signature limités et un contrôle clair des artefacts. Chaque étape doit laisser des journaux traçables pour identifier les problèmes de dépendances, de compilation, de signature ou d’export.
-
01
Recevoir le déclencheur du dépôt
Déclenchez le build après une fusion dans la branche principale, un tag de version ou une tâche manuelle. Inscrivez le nom de branche, le hash du commit, la version et le numéro de build dans le contexte de la tâche afin de relier chaque artefact à son code source.
-
02
Restaurer les dépendances verrouillées
Installez les dépendances Swift Package, CocoaPods ou JavaScript selon le fichier de verrouillage. Séparez les caches par projet, version des outils et résumé du lockfile afin d’éviter le partage de dépendances incorrectes entre branches.
-
03
Accorder les droits de signature
Déverrouillez uniquement les certificats et profils nécessaires pendant le build, en limitant l’accès du Runner. Fermez l’accès temporaire à la fin et n’écrivez ni clés privées, ni jetons, ni mots de passe complets dans les journaux.
-
04
Lancer les tests et l’archivage
Exécutez d’abord les contrôles statiques et les tests unitaires, puis Xcode Archive. En cas d’échec, arrêtez immédiatement la signature et conservez les résultats de test, la sortie du compilateur et les cas en échec.
-
05
Exporter l’IPA
Générez l’IPA avec une configuration d’export versionnée et conservez dSYM, archive et journaux d’export. Ne gardez pas uniquement le paquet final : le diagnostic des crashs et le suivi des versions en dépendent.
-
06
Effectuer les contrôles avant envoi
Vérifiez le Bundle ID, la version, le numéro de build, la signature, le manifeste de confidentialité et les changements de taille du paquet. Une fois les contrôles validés, transmettez les artefacts à l’étape d’envoi ou d’approbation.
Choisir une configuration selon la charge
Trois niveaux pour trois types de charge de build
Examinez d’abord le pic de mémoire, le nombre de tâches simultanées et la durée d’une tâche avant de choisir la machine. Ne vous fiez pas uniquement au nom du projet et ne confondez pas la croissance du cache disque avec un besoin de calcul.
Adapté au développement quotidien, aux pipelines multi-branches, aux builds natifs React Native ou Flutter et aux équipes qui doivent conserver davantage de caches de dépendances.
Louer ZoneMini M4 PlusAdapté aux builds parallèles intensifs, à l’inférence de grands modèles, aux tâches média volumineuses et aux traitements par lots de longue durée. Validez en priorité les tâches gourmandes en mémoire sur ce niveau.
Louer ZoneMini M4 ProTraitez plusieurs Runners fixes comme des ressources planifiables, pas comme un poste de travail partagé
L’objectif d’une ferme de build n’est pas d’envoyer chaque tâche vers n’importe quelle machine, mais de définir une responsabilité stable pour chaque nœud. Labels, files, limites de cache, archivage des journaux et répartition géographique doivent être conçus ensemble pour localiser les échecs et prévoir la capacité.
RUNNER ASSIGNMENT
Les labels déterminent la destination
ios-light
Validation des commits et tests unitaires
Priorité aux tâches courtes, concurrence limitée, libération immédiate de la file en cas d’échec
ios-release
Archives signées et paquets candidats à la publication
Chaîne d’outils fixe et périmètre de droits contrôlé, avec journal d’export complet
cross-platform
React Native et Flutter
Séparer les caches JavaScript, CocoaPods et de compilation native
high-memory
Inférence de modèles et tâches parallèles volumineuses
Associer à ZoneMini M4 Pro et consigner le pic mémoire ainsi que le répertoire de sortie
Séparer les files selon la durée et les droits
Ne mélangez pas validation des commits, archivage de publication et tâches gourmandes en mémoire dans une file indifférenciée. Attribuez un label aux tâches longues afin d’éviter une attente prolongée des tests courts.
Isoler le cache par projet et par version
Les clés de cache doivent au minimum inclure le projet, la stratégie de branches, la version des outils et le résumé du lockfile. En cas d’anomalie, autorisez le nettoyage du projet concerné sans vider tout le nœud.
Centraliser l’archivage des journaux d’échec
Conservez l’identifiant du commit, le label du Runner, la version de Xcode, le résumé des dépendances, l’étape en échec et les journaux anonymisés. Définissez une durée de conservation et n’y incluez aucun jeton d’accès.
Rapprocher les nœuds du dépôt et de l’équipe
Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong et est des États-Unis sont des emplacements disponibles. Tenez compte en priorité de l’emplacement du dépôt, du fuseau horaire de l’équipe et de la direction de livraison des artefacts.
Avec React Native et Flutter, le goulot d’étranglement se situe souvent dans la couche native
Le code JavaScript ou Dart peut être développé dans plusieurs environnements, mais la résolution des dépendances iOS, les tests sur simulateur, la signature et l’archivage nécessitent toujours macOS et Xcode. Un Mac cloud fixe déplace ces étapes de l’ordinateur personnel vers le pipeline de l’équipe.
React Native
Gérer séparément les dépendances JavaScript et natives
- Restauration des dépendances :Installez les paquets Node.js selon le lockfile, puis restaurez les dépendances CocoaPods dans le répertoire iOS.
- Limites du cache :Définissez des clés distinctes pour le cache du gestionnaire de paquets, le cache Pods et DerivedData ; ne mettez pas tout le répertoire de travail en cache.
- Ordre des tests :Exécutez d’abord la vérification des types et les tests JavaScript, puis les tests unitaires natifs ou les contrôles sur simulateur.
- Build signé :La branche de publication utilise un Scheme fixe pour générer Archive, IPA, dSYM et journaux d’export.
- Stratégie multi-branches :Les branches de fonctionnalité servent uniquement à la validation ; accordez les droits de signature aux branches candidates pour éviter de générer un paquet de publication à chaque commit.
Flutter
Consigner séparément les étapes Dart et Xcode
- Vérification de l’environnement :Figez les versions de Flutter, Dart, CocoaPods et Xcode, puis affichez leur résumé au début de la tâche.
- Dépendances natives :Restaurez les dépendances des plugins iOS et vérifiez s’ils exigent des autorisations système supplémentaires ou une version minimale de déploiement.
- Tests sur simulateur :Séparez les tests de composants des tests sur simulateur iOS et conservez rapports et captures en cas d’échec.
- Archivage signé :Générez l’Archive iOS avec une configuration contrôlée, puis vérifiez les options d’export et le résultat de la signature.
- Isolation des branches :Utilisez des répertoires de travail distincts pour les branches stables et expérimentales afin d’éviter l’écrasement mutuel des artefacts et des caches.
CHECK 01
Le lockfile est-il mis à jour avec le commit ?
Une modification des dépendances sans mise à jour du lockfile rend difficile la reproduction d’un succès local suivi d’un échec en CI.
CHECK 02
Les modules natifs exigent-ils une nouvelle chaîne d’outils ?
Avant de mettre à niveau un plugin, vérifiez les conditions Xcode, la cible de déploiement et CocoaPods, puis mettez à jour le nœud fixe.
CHECK 03
Le cache peut-il être invalidé sans risque ?
Tout cache doit pouvoir être supprimé puis recréé ; il ne doit jamais constituer l’unique source des dépendances.
Confiez les expérimentations continues aux nœuds à grande mémoire
Le Mac dans le cloud convient à la préparation des modèles, à l’inférence, au suivi des métriques et à l’export des résultats dans un environnement Apple Silicon fixe. Il ne remplace pas une plateforme d’entraînement ; il sert surtout à valider l’inférence locale, exécuter des expériences par lots et observer les ressources dans l’environnement macOS cible.
Configuration haute mémoire recommandée
ZoneMini M4 Pro
M4 Pro · 64GB · 2TB
01
Préparer le modèle et vérifier les fichiers
Consignez la version et la source du modèle, le résumé des fichiers, la méthode de quantification et la version du script. Vérifiez l’intégrité des gros fichiers avant de les placer dans le répertoire d’expérience.
02
Isoler l’environnement d’exécution
Créez un environnement indépendant pour chaque expérience et verrouillez les paquets Python et dépendances natives. Une mise à niveau temporaire ne doit pas modifier une base déjà validée.
03
Exécuter l’inférence par lots
Augmentez progressivement la charge selon la taille des lots, la longueur des entrées et le niveau de concurrence. Consignez le pic mémoire, la durée, les échantillons en échec et le nombre de nouvelles tentatives.
04
Exporter les métriques et les résultats
Exportez ensemble les paramètres, le résumé de l’environnement, les fichiers de sortie et les journaux anonymisés. Ne conservez pas uniquement la moyenne finale : les échantillons atypiques doivent aussi être suivis.
Confiez les transcodages longs à un nœud fixe et renvoyez les fichiers finis au système d’archivage
Les tâches audio-vidéo sollicitent généralement le processeur, la mémoire et le disque. Un workflow efficace sépare synchronisation des sources, traitement temporaire, contrôle qualité et retour final, sans transformer le disque de travail du Mac cloud en médiathèque permanente.
Synchroniser les médias et vérifier leur résumé
Synchronisez les fichiers source, sous-titres, pistes audio et paramètres selon la liste de tâches. Après le transfert, contrôlez la taille ou le résumé des fichiers afin de ne pas lancer une tâche longue sur des médias incomplets.
- Entrée
- Vidéo source, pistes audio, sous-titres, tableau de paramètres
- Enregistrement
- Résumé du fichier, exigences d’encodage, nom de sortie
Transcoder et générer les fichiers proxy
Répartissez les tâches par résolution, format d’encodage ou lot de projet. Si vous avez besoin de formes d’onde, de fichiers proxy ou de miniatures, enregistrez leurs paramètres dans la même tâche.
- Traitement
- Transcodage par lots, formes d’onde, fichiers proxy, miniatures
- Isolation
- Répertoire temporaire et liste d’échecs distincts pour chaque lot
Contrôle automatique puis vérification manuelle
Vérifiez d’abord la durée, la résolution, le nombre de pistes et l’intégrité des fichiers de sortie, puis contrôlez manuellement les séquences clés. Relancez uniquement le lot concerné en cas d’échec.
- Automatique
- Durée, dimensions, pistes audio, intégrité des fichiers
- Manuel
- Image, son, sous-titres et séquences clés
Renvoyer les fichiers finis et nettoyer le disque temporaire
Renvoyez les fichiers finis, les journaux de traitement et la liste des échecs vers le stockage indiqué par l’équipe. Une fois le transfert confirmé, supprimez les fichiers temporaires pour éviter de saturer le disque local.
- Artefacts
- Fichiers finis, journaux, liste des tâches en échec
- Limite
- Le disque de travail ne sert pas à l’archivage permanent
Transformez les contrôles pré-envoi en garde-fou du pipeline
Une archive réussie ne signifie pas que l’application est prête à être soumise. Vérifiez avant la livraison les informations de version, la signature, le manifeste de confidentialité, la validation de l’archive, les captures et les notes de publication. ZoneMini fournit l’environnement d’exécution, mais ne remplace pas les règles de la plateforme de distribution.
RELEASE GATE
Livrez le paquet candidat uniquement après validation des six contrôles
Conservez pour chaque build candidat les résultats des contrôles, le hash du commit, la version et le numéro de build. En cas de problème, revenez à l’étape concernée au lieu de modifier au dernier moment une configuration non documentée.
-
01
Version et numéro de build
Vérifiez leur cohérence avec la branche de publication, l’historique des changements et le paquet candidat ; le numéro de build ne doit pas être dupliqué.
-
02
Signature et profils de provisionnement
Vérifiez que le Bundle ID, l’identité de signature, les déclarations d’autorisations et le mode d’export correspondent à la cible.
-
03
Manifeste de confidentialité
Contrôlez les déclarations de confidentialité de l’application et de ses dépendances, et confirmez que tout nouveau SDK est inclus dans la vérification.
-
04
Validation de l’archive
Conservez la sortie de validation et corrigez les symboles manquants, les incohérences d’autorisations ou les réglages de build non pris en charge.
-
05
Captures et métadonnées
Préparez captures, descriptions et notes de mise à jour selon l’appareil, la langue et la version cibles, puis vérifiez les noms de fichiers.
-
06
Régression avant soumission
Sur le paquet candidat, vérifiez le démarrage, la connexion, les parcours clés, les erreurs réseau et les scénarios de mise à niveau.
Séparer l’environnement d’exécution des règles de validation
Le Mac cloud peut exécuter en continu les builds, contrôles et préparations d’artefacts, mais le contenu, les métadonnées, les exigences de conformité et la décision finale de validation relèvent des règles de la plateforme concernée. L’équipe doit conserver ses propres approbations et procédures de retour arrière.
Combiner les nœuds selon les files, les droits et le périmètre de collaboration
Le nombre de nœuds ne doit pas dépendre uniquement de la taille de l’équipe. Commencez par confirmer le nombre de tâches simultanées, la nécessité d’isoler les droits de signature, le partage possible des caches ainsi que la répartition des membres et des dépôts.
1 nœud permanent
Développeur indépendant
Un environnement fixe suffit pour le développement quotidien, les tests et l’archivage des paquets candidats. Inscrivez versions des dépendances, étapes de signature et scripts de nettoyage dans le dépôt afin de réduire les écarts entre l’ordinateur local et l’environnement distant.
- Un projet léger peut commencer avec ZoneMini M4 Core
- Pour un projet multiplateforme ou davantage de cache, privilégiez ZoneMini M4 Plus
- Exportez régulièrement les archives, journaux et documents à conserver
2 files de tâches
Équipe CI
Séparez au minimum la validation des commits et l’archivage de publication. Lorsque le volume augmente, ajoutez des nœuds par label au lieu de faire exécuter tous les tests courants par un Runner disposant des droits de signature.
- La file des tests courts répond en priorité ; les archives longues utilisent une file dédiée
- Isolez les caches par projet et archivez uniformément les journaux d’échec
- Associez les tâches gourmandes en mémoire ou parallèles à ZoneMini M4 Pro
5 nœuds au choix
Équipe répartie sur plusieurs régions
Choisissez entre Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong et est des États-Unis selon la proximité du dépôt, des principaux membres ou de la chaîne de livraison. Ne répartissez pas les nœuds uniquement selon le lieu de résidence des membres.
- Lorsque le dépôt est fréquemment sollicité, privilégiez sa région
- Pour une collaboration graphique fréquente, tenez compte aussi des principaux utilisateurs
- Utilisez la même liste d’outils et le même format de journaux sur tous les nœuds
À confirmer d’abord
Type de tâches et pic de concurrence
Listez les tâches de build, de test, d’inférence et de traitement média susceptibles de s’exécuter simultanément.
À confirmer ensuite
Mémoire, stockage et durée
Choisissez la configuration parmi les trois niveaux selon les pics réels, et non selon le nom du projet.
À confirmer enfin
Nœud, durée et moyens de paiement
Toutes les commandes sont réglées en USD. Seuls USDT-TRC20 et Visa / Mastercard / Amex (via Stripe) sont acceptés.
Préparer la commande
Choisissez le nœud et la configuration selon votre charge
Préparez l’usage prévu, le nombre de tâches simultanées, le nœud cible, la durée de location et le stockage requis. Pour connaître les modes de connexion, consultez le guide d’accès à distance ; pour des conseils de configuration, contactez l’équipe.