Durée, connexion, build :
que faut-il vérifier ?

Le paiement est effectué à l’avance pour la période choisie ; la configuration et les options sont facturées séparément. Par exemple, l’ArmRDP M4 Base est affiché à $21.1/jour, $57.1/semaine, $105.7/mois et $287.5/trimestre. Ce sont quatre tarifs distincts, et non le tarif journalier multiplié par le nombre de jours.

Pour comparer, tenez compte de la durée d’utilisation prévue et du stockage nécessaire. Pour un test ponctuel, commencez à la journée ; pour des livraisons régulières, comparez le tarif hebdomadaire ; pour un runner utilisé en continu, comparez les tarifs mensuel et trimestriel. Les dates de début et de fin, le montant dû et l’échéance de la commande sont ceux affichés sur la page de confirmation du portail et dans l’historique de commande.

Ne partez pas du principe que le premier paiement active le renouvellement automatique. Vérifiez dans le portail le paramétrage du renouvellement, la date d’échéance et les factures en attente de votre abonnement. Le statut affiché pour l’abonnement fait foi quant à l’activation et à la date d’effet du renouvellement automatique.

Avant une livraison, vérifiez que la période de location couvre l’archivage, la signature et le transfert des artefacts. Avant la fin de la location, cessez d’accepter de nouvelles tâches, attendez que la file soit vide, puis exportez le code, les sauvegardes des certificats et les artefacts de build. Ne comptez pas sur le disque de la machine après l’échéance pour conserver vos sauvegardes à long terme.

Le catalogue propose des SSD supplémentaires de +1TB et +2TB, ainsi qu’une option Thunderbolt 5 parallèle facturée par machine. Consultez d’abord les modifications proposées pour votre commande dans le portail. Avant de confirmer, vérifiez les modalités d’ajout, le début de la facturation et les éventuelles adaptations nécessaires aux tâches en cours ; l’activation immédiate et le calcul au prorata du temps restant ne sont pas garantis.

Si l’option souhaitée n’est pas proposée dans le portail, ouvrez un ticket en indiquant l’identifiant de la machine, l’option voulue, l’espace disponible et la date souhaitée. Augmenter le disque n’augmente pas la mémoire. Si DerivedData, les runtimes de simulateur et les archives occupent de plus en plus d’espace, examinez d’abord l’utilisation du disque avant d’ajouter de la capacité.

Seuls USDT-TRC20 et Visa / Mastercard / Amex (via Stripe) sont acceptés. Tous les paiements sont en dollars américains (USD). Le symbole $ affiché sur le site désigne le dollar américain ; aucune conversion en monnaie locale n’est effectuée.

Les moyens de paiement disponibles sont ceux renvoyés par l’interface du portail. Avant de payer, vérifiez la configuration, l’emplacement, la durée et les options de la commande. Conservez le numéro de commande et le justificatif de paiement pour toute demande concernant une facture ou un paiement.

Retournez dans le portail et actualisez la commande pour vérifier qu’il s’agit bien de la même facture. Le retour automatique du navigateur vers le site ne confirme pas le paiement. Ne payez pas une seconde fois tant que le statut n’a pas été vérifié.

Avec USDT-TRC20, vérifiez le réseau, les informations du destinataire et le montant, puis conservez l’identifiant de transaction. Pour un paiement par carte, gardez le résultat du paiement et le numéro de facture. Si le statut ne change toujours pas, ouvrez un ticket depuis le portail. Ne communiquez jamais le numéro complet de votre carte, son cryptogramme ni votre mot de passe dans un ticket.

Il s’agit d’un Mac mini physique dédié, pas d’une machine virtuelle. Pendant toute la durée de la location, vous disposez du nœud entier, qui n’est pas partagé avec d’autres clients. L’interface graphique et la ligne de commande macOS sont pleinement accessibles ; Xcode, les simulateurs et Metal s’exécutent nativement sur la machine physique.

Le catalogue propose trois configurations : ArmRDP M4 Base (M4 / 16GB / 256GB), ArmRDP M4 Plus (M4 / 24GB / 512GB) et ArmRDP M4 Pro (M4 Pro / 64GB / 2TB). Pour choisir, tenez compte des pics de mémoire et de l’espace de travail sur disque ; le nom de la puce ne suffit pas à déterminer si une configuration convient.

Les droits du compte sont ceux attribués par le portail. Lors de la première connexion, utilisez id pour afficher les utilisateurs et les groupes, puis sudo -l pour vérifier les commandes d’administration autorisées. Avant d’installer un logiciel, d’enregistrer un service ou de modifier le réseau avec sudo, vérifiez que vous disposez des droits nécessaires. Utiliser sudo n’implique pas d’activer la connexion root à distance.

Avant de réinstaller le système ou d’en changer la version, sauvegardez vos répertoires de travail, vos éléments de signature et votre configuration. Vérifiez dans le portail les opérations de réinstallation disponibles ou ouvrez un ticket pour confirmer la version souhaitée. N’effacez pas le disque et ne supprimez pas la configuration réseau depuis une session à distance : vous pourriez aussi perdre tout accès pour rétablir la machine.

5 emplacements sont disponibles : Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong et États-Unis Ouest. Les trois configurations sont proposées dans chacun d’eux ; leur disponibilité en temps réel est indiquée dans le portail.

Pour les équipes qui utilisent souvent l’interface graphique, comparez la qualité de la connexion entre les ingénieurs et le nœud. Pour les équipes qui automatisent principalement leurs builds, tenez aussi compte de l’emplacement du dépôt, des sources de dépendances et de la destination des artefacts. La distance géographique n’est qu’un indicateur : le routage des opérateurs, la bande passante et la perte de paquets comptent également. Tous les nœuds fonctionnent normalement 365 jours par an ; vous choisissez vos créneaux de build.

Un changement d’emplacement ne signifie pas que vous pouvez basculer immédiatement en conservant le disque et l’adresse actuels. Le changement de nœud implique une nouvelle machine physique, de nouvelles informations de connexion et la migration des données. Vérifiez d’abord les modalités de modification de votre commande en ouvrant un ticket depuis le portail.

Côté technique, préparez d’abord la même version de la toolchain sur le nœud cible, transférez le dépôt et les configurations nécessaires, puis validez un archivage et une signature. Basculez ensuite les tags des runners et le routage des tâches. Ne touchez à l’ancien nœud qu’une fois les artefacts vérifiés, afin de ne pas interrompre trop tôt votre seul environnement de build opérationnel.

Vous pouvez conserver plusieurs versions de Xcode, à condition qu’elles soient compatibles avec la version actuelle de macOS, et choisir la toolchain pour chaque projet. Utilisez xcodebuild -version et xcode-select -p pour vérifier l’environnement actuel. Dans un pipeline, vous pouvez définir DEVELOPER_DIR pour pointer vers le Xcode voulu et éviter de modifier sans cesse la sélection globale d’un projet à l’autre.

Lorsque vous verrouillez les versions, consignez également le SDK, le runtime du simulateur, les fichiers de verrouillage des dépendances et les scripts de build. Avant une mise à niveau, dupliquez un pipeline de validation et vérifiez que l’archivage, codesign et l’export fonctionnent, puis mettez à jour les tâches habituelles. Un SSD plus grand peut accueillir davantage de versions, mais ne supprime pas les limites de compatibilité entre le système et Xcode.

Les simulateurs s’exécutent nativement sur le nœud physique, à condition que le runtime compatible avec Xcode soit installé. Utilisez VNC pour examiner les problèmes d’interface et la ligne de commande pour lancer les tâches automatisées. Lorsque plusieurs simulateurs et archivages tournent en même temps, surveillez la pression mémoire et l’espace disque disponible.

Traitez les certificats et les profils de provisioning comme des éléments sensibles. Nous recommandons de créer un trousseau dédié à la CI et de stocker les identifiants dans les variables protégées du pipeline, sans les inclure dans le dépôt ni les joindre à un ticket. Vérifiez la signature une fois avec le même compte d’exécution, puis confiez la tâche au runner sans surveillance.

Le nombre de machines ne se déduit pas du seul nombre de builds quotidiens. Commencez avec 1 machine et 1 tâche en parallèle sur un vrai projet. Mesurez la durée totale des tâches, le temps d’attente dans la file, le pic de mémoire et la taille des archives : ces données sont plus utiles que le temps de compilation d’un projet vide.

Une machine peut héberger plusieurs processus de runner, mais ils partagent son processeur, sa mémoire et son disque. Pour exécuter simultanément des archivages indépendants, ajoutez des nœuds dédiés et répartissez les tâches à l’aide de tags. Attribuez à chaque tâche un répertoire de travail, un chemin DerivedData et un environnement de signature temporaires distincts afin d’éviter les conflits de cache.

SSH permet d’installer des dépendances, d’exécuter des scripts, de consulter les journaux et de gérer les services CI. Le partage d’écran VNC sert à utiliser Xcode, à consulter les simulateurs et à diagnostiquer les problèmes d’interface graphique. Les deux méthodes donnent accès au même Mac dans le cloud, et non à deux environnements séparés.

Pour la première connexion, récupérez l’adresse de la machine, le port et les identifiants dans le portail, puis vérifiez les informations de l’hôte avant de vous connecter. Une fois configurées, les tâches de build doivent être exécutées en continu par le service runner ; ne comptez pas sur une session graphique laissée ouverte ou une fenêtre SSH locale.

Le nom du nœud ne permet pas de déterminer à lui seul la latence de votre réseau. La réactivité de SSH dépend surtout du temps aller-retour ; celle de VNC dépend aussi de la résolution, des changements d’image, des paramètres de compression et de la bande passante disponible. Un seul test ping ne reflète pas l’expérience lors d’une utilisation continue.

En cas de ralentissement, vérifiez d’abord si SSH fonctionne normalement sur le même réseau, puis réduisez la résolution ou la profondeur de couleur de VNC et désactivez les animations inutiles. Dans votre ticket, indiquez le système du client, le nœud, la méthode de connexion, les heures concernées et les pertes de paquets. Précisez si la saisie, l’affichage ou la connexion elle-même est lente.

Commencez par modifier les identifiants fournis et ajouter votre clé publique SSH personnelle. Vérifiez que l’authentification par clé fonctionne dans une seconde session ; une fois cette vérification faite, vous pouvez désactiver l’authentification SSH par mot de passe selon votre politique de sécurité. Avant de modifier le pare-feu ou les restrictions d’adresses IP sources, conservez un accès de secours déjà testé.

Privilégiez un tunnel SSH pour accéder à VNC afin de ne pas exposer directement le partage d’écran à des sources inutiles. Chaque membre de l’équipe doit utiliser sa propre clé ; révoquez-la rapidement en cas de départ ou de changement de rôle. Lors du renouvellement des identifiants, vérifiez également les variables des runners, les scripts d’automatisation et les informations enregistrées dans les clients locaux.