Ce parcours suit l’ordre réel des opérations. Préparez d’abord votre compte, votre clé publique SSH et les versions de vos outils, puis choisissez un serveur physique dédié, un nœud et une durée de location. À la livraison, vérifiez la machine, connectez-vous et lancez le build.
Tout le parcours s’effectue sur un nœud Mac physique dans le cloud. Chaque commande correspond à une machine physique dédiée, non virtualisée. Idéal pour le développement iOS/macOS, les files CI/CD et les tests nécessitant macOS.
Ces informations influencent le choix de la configuration, du nœud et de la durée. Les confirmer à l’avance réduit les ajustements après la livraison de la machine.
Vérifiez que votre adresse e-mail est valide et que vous pouvez accéder à la console pour consulter les commandes, les informations d’hôte et les tickets. Les informations de connexion livrées doivent rester dans un environnement contrôlé.
Créez de préférence une paire de clés dédiée à votre Mac dans le cloud. Transmettez uniquement la clé publique et conservez la clé privée sur un appareil local protégé. Ne l’envoyez jamais par e-mail ou via un ticket.
Tenez compte de la localisation des développeurs, du dépôt de code, de la chaîne de signature et du stockage des artefacts. Ne choisissez pas un nœud uniquement sur la base du ping le plus faible lors d’un seul test.
Déterminez s’il s’agit d’un correctif urgent, d’une validation courte, d’itérations continues ou d’un pipeline trimestriel, puis choisissez la durée adaptée : jour, semaine, mois ou trimestre.
Notez la version majeure de Xcode, le SDK cible, la version minimale de déploiement, les dépendances Ruby et fastlane, ainsi que le mode d’exécution requis par le CI Runner.
Les deux configurations sont des Mac Mini M4 physiques dédiés. Commencez par le type de tâche, puis vérifiez la mémoire et l’espace de travail local ; inutile de réserver pour une courte tâche une configuration qui ne sera pas exploitée.
Convient à l’archivage d’un seul projet, aux correctifs urgents, à la vérification des certificats, aux tests automatisés légers et aux tâches qui n’ont pas besoin de conserver plusieurs gros simulateurs ou processus de build simultanément.
Convient au développement quotidien, aux builds parallèles, aux caches de dépendances volumineux, aux CI Runners persistants et aux tâches de validation d’inférence de modèles dans la limite de la mémoire disponible.
Si votre projet termine de manière fiable un build unique avec 16 Go de mémoire, choisissez DeployMini M4 16. Si le build, les tests, les simulateurs ou l’inférence s’exécutent simultanément, choisissez DeployMini M4 24 et évaluez le stockage supplémentaire selon le volume de données du projet.
Les nœuds disponibles sont Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong et États-Unis Ouest. Les deux configurations peuvent être commandées sur les cinq nœuds ; la disponibilité réelle est celle affichée en temps réel dans la console.
Adapté aux workflows dont l’équipe, le dépôt de code ou les services d’artefacts se trouvent principalement en Asie du Sud-Est.
Deux configurations disponiblesAdapté aux tâches de développement et de build couvrant le Japon et les liaisons d’Asie de l’Est.
Deux configurations disponiblesAdapté aux équipes dont les développeurs, les dépôts ou les cibles de livraison se concentrent en Corée du Sud et en Asie du Nord-Est.
Deux configurations disponiblesAdapté aux workflows qui doivent combiner les itinéraires réseau de la Chine du Sud et de l’Asie du Sud-Est.
Deux configurations disponiblesAdapté aux projets dont le code, les artefacts et la chaîne de services finale se trouvent principalement sur la côte ouest de l’Amérique du Nord.
Deux configurations disponiblesLa location à la journée convient aux correctifs urgents et aux validations courtes ; à la semaine, au développement et aux tests intensifs ; au mois, aux itérations continues ; au trimestre, aux workflows CI/CD ou d’équipe plus stables. Vérifiez encore le modèle, le nœud, l’extension de stockage et la durée avant de valider.
Nous acceptons uniquement USDT-TRC20 et Visa / Mastercard / Amex (via Stripe). Tous les frais sont facturés en dollars américains (USD) ; la passerelle effectivement disponible est indiquée dans la console.
Ouvrez la commande correspondante dans la console et vérifiez chaque élément livré. En cas d’incohérence, conservez le numéro de commande et une capture d’écran expurgée, puis envoyez un ticket depuis la console.
Vérifiez qu’il s’agit bien du DeployMini M4 16 ou du DeployMini M4 24 sélectionné, puis confirmez les informations de la puce M4.
Vérifiez 16 Go / SSD 256 Go ou 24 Go / SSD 512 Go, ainsi que le stockage supplémentaire indiqué dans la commande.
Vérifiez que Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong ou États-Unis Ouest correspond à la commande.
Enregistrez l’adresse de l’hôte, le nom d’utilisateur et les informations de vérification de l’empreinte. Ne placez pas les identifiants de connexion dans un dépôt public.
Confirmez la date de début, la durée et la suite prévue, en réservant du temps pour exporter et nettoyer les données.
Testez d’abord SSH, le DNS et les outils de base, puis récupérez le code. Vous pourrez ainsi distinguer plus facilement un problème de connexion, d’environnement ou de projet.
Indiquez le numéro de commande, le nœud, l’heure de l’incident, le résultat attendu et les informations expurgées. N’envoyez ni mot de passe, ni clé privée, ni identifiants de paiement complets.
L’exemple ci-dessous utilise l’adresse réservée à la documentation pour illustrer l’ordre de connexion. L’adresse réelle, le nom d’utilisateur et l’empreinte sont ceux fournis dans la console ; ne vous connectez pas en copiant les valeurs de l’exemple.
$ chmod 600 ~/.ssh/deploymini_ed25519
$ ssh -i ~/.ssh/deploymini_ed25519 deploy@203.0.113.24
The authenticity of host '203.0.113.24' can't be established.
ED25519 key fingerprint is SHA256:EXAMPLE-FINGERPRINT.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '203.0.113.24' to known hosts.
Last login: current session
deploymini-m4:~ deploy$ connection readyCommencez par les vérifications en lecture seule, puis installez les dépendances du projet et lancez le build. Conservez à chaque étape les versions et un résumé de la sortie pour pouvoir réutiliser la procédure dans le CI.
Exécutez xcodebuild -version et xcode-select -ppour vérifier la version majeure de Xcode requise par le projet et le répertoire développeur actuellement utilisé.
xcodebuild -version
xcode-select -pAprès avoir ouvert le répertoire du projet, listez le workspace, le project et les schemes afin d’éviter d’injecter des valeurs locales par défaut dans le script de build distant.
xcodebuild -list \
-workspace Example.xcworkspaceDéfinissez le workspace, le scheme et la configuration, puis enregistrez les journaux et le code de sortie dans le répertoire de tâche pour faciliter le diagnostic des dépendances ou de la signature.
xcodebuild \
-workspace Example.xcworkspace \
-scheme Example \
-configuration Release buildFigez les versions de Ruby et des dépendances, exécutez d’abord le lane cible manuellement, puis regroupez les paramètres non sensibles dans des variables réutilisables. Stockez les valeurs sensibles dans un emplacement de gestion des secrets contrôlé.
bundle install
bundle exec fastlane buildUne machine physique dédiée ne doit pas être l’emplacement unique des données du projet. Intégrez la migration et la révocation à votre planning au lieu d’attendre la dernière connexion.
Copiez les archives, journaux, résultats de tests et caches à conserver. Après le transfert, vérifiez la taille ou l’empreinte des fichiers et assurez-vous que la copie locale est lisible.
Migrez le répertoire de travail du projet, les modèles de configuration et les informations nécessaires vers un emplacement géré par l’équipe. Chiffrez les données sensibles avant de les intégrer au processus de sauvegarde.
Supprimez la clé publique SSH temporaire, les jetons du projet, les informations d’enregistrement du Runner et les variables d’environnement à durée limitée, puis confirmez dans les systèmes concernés que les identifiants sont invalides.
Consultez la console pour vérifier la durée actuelle et le plan d’utilisation à venir. Si les builds doivent continuer, confirmez d’abord que les données, le nœud et la configuration répondent toujours aux besoins de la tâche.
Choisissez l’une des deux machines physiques dédiées, sélectionnez une région parmi les cinq nœuds, puis confirmez une durée à la journée, à la semaine, au mois ou au trimestre.