Guide d’assistance par tâche

De la première connexion au dépannage des builds, trouvez la prochaine étape

DebugMac fournit des nœuds physiques Apple Silicon dédiés, pas des machines virtuelles. Vérifiez d’abord les identifiants, la région et la chaîne d’outils, puis utilisez les sorties de commande pour localiser les problèmes de connexion, de build, de stockage ou de réseau.

Louer un Mac dans le cloud Voir le guide de démarrage
Équipement fourni
Nœud physique Debug M4 dédié
Modes de connexion
SSH et interface graphique macOS
Canal d’assistance
Tickets du panneau et e-mail d’assistance
BREAKPOINT REVIEW DESK Fiche de diagnostic
Vérification point par point
CASE / BUILD-042 À reproduire

Figez d’abord les entrées, puis vérifiez l’environnement d’exécution

Nœud
JP · Debug M4
Tâche
Xcode Archive
Accès
Clé publique SSH
Preuves
Commandes, horodatage, logs anonymisés
Parcours de diagnostic
  1. 01Vérifier l’empreinte de l’hôteConfirmer que la cible n’a pas changé
  2. 02Consigner les versions de la chaîne d’outilsFiger Xcode et les dépendances
  3. 03Réduire le périmètre du problèmeDistinguer le poste local, le réseau et la session du nœud
EntréesCommande et région ExécutionReproduction et échantillonnage RésultatTicket vérifiable
Index de l’assistance

Six catégories de tâches affichées ensemble, sans cacher les étapes clés dans un filtre

La sélection d’une catégorie localise et met en évidence le chapitre correspondant. Le reste du guide reste visible pour comparer les conditions en amont et en aval.

Première connexion

Vérifier les identifiants et l’empreinte de l’hôte

Préparez l’adresse, le nom d’utilisateur et la clé publique SSH, vérifiez d’abord l’empreinte, puis établissez les sessions en ligne de commande et graphiques.

Build quotidien

Figer Xcode et les paramètres d’archivage

De l’état du dépôt et de la chaîne d’outils à la signature et à l’export de l’archive, conservez les versions permettant de reproduire le résultat.

Automatisation CI

Rendre le runner traçable et nettoyable

Limitez la concurrence, gérez explicitement les caches et répertoires temporaires, puis rapatriez les sorties de build essentielles dans le pipeline.

Extension du stockage

Vérifier la capacité, le montage et les unités en parallèle

Confirmez les options avant l’activation, puis vérifiez après livraison la capacité du disque, le point de montage, le système de fichiers et la cible de lecture-écriture.

Diagnostic réseau

Examiner séparément le poste local, le réseau et la session

Réduisez progressivement le périmètre avec des tests de latence, de route, de port et de transfert, au lieu de conclure sur un seul ping.

Gestion du compte

Transformer le problème en ticket exploitable

Joignez l’identifiant de commande, la région, l’heure, les étapes de reproduction et les logs anonymisés afin de limiter les demandes répétées.

SSH et session graphique

Vérifiez d’abord la cible, puis enregistrez une base fiable

L’adresse, le nom d’utilisateur, l’empreinte de l’hôte et l’état d’activation indiqués dans le reçu de livraison doivent appartenir à la même commande. En cas d’écart, interrompez la connexion et vérifiez via un ticket dans le panneau.

Préparer la connexion

Préparez la clé privée SSH locale, la correspondance avec la clé publique, le reçu de livraison et un réseau stable. Ne collez pas de clé privée, d’identifiants complets ni de configuration non anonymisée dans un ticket.

  • Vérifiez que les permissions de la clé privée locale autorisent uniquement sa lecture par l’utilisateur courant.
  • Vérifiez que la région de la commande est Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong ou Ouest des États-Unis.
  • Vérifiez séparément l’empreinte de l’hôte figurant sur le reçu avant la première connexion.
  • Notez l’heure de la première connexion réussie, la version du système et la capacité du disque par défaut.
Voir toutes les étapes de démarrage
  1. 01 Préparer les identifiants

    Relevez l’adresse de l’hôte, le nom d’utilisateur et l’empreinte dans le reçu de livraison ; conservez la clé privée dans un chemin local contrôlé et ne la transmettez ni par chat ni par ticket.

  2. 02 Vérifier l’empreinte

    L’empreinte affichée lors de la première connexion SSH doit correspondre au reçu. Si elle change soudainement après une connexion antérieure, ne supprimez pas directement l’enregistrement local pour réessayer.

  3. 03 Tester la connexion par clé

    Exécutez d’abord des commandes en lecture seule pour confirmer l’identité, l’architecture Apple Silicon, l’heure système et l’espace disque disponible, puis ouvrez le dépôt ou le répertoire de build.

  4. 04 Démarrer la session graphique

    Vérifiez les identifiants de la session graphique, la résolution d’affichage et la disposition du clavier ; après la première ouverture, testez une déconnexion sécurisée puis une reconnexion.

  5. 05 Gérer les déconnexions

    Distinguez d’abord l’interruption du réseau local, l’inaccessibilité du port SSH et l’interruption de la session graphique. Si la ligne de commande reste disponible, enregistrez en priorité les logs et l’état de la tâche.

Conservez d’abord trois éléments de preuve en cas d’échec de connexion

Notez l’heure locale, le texte complet de l’erreur et le résultat du contrôle du port effectué depuis le même réseau. Ne réinitialisez pas les identifiants en boucle : vous écraseriez l’état au moment du problème.

Workflow Xcode

Figez ensemble le dépôt, la chaîne d’outils et les paramètres d’archive

Un même commit peut produire des résultats différents selon Xcode, le fichier de verrouillage des dépendances ou les paramètres de signature. Pour diagnostiquer, figez d’abord les entrées et ne mettez pas plusieurs dépendances à niveau simultanément.

01

Récupérer le dépôt

Consignez le hash du commit, la branche, l’état des sous-modules et les fichiers de verrouillage des dépendances. Vérifiez que l’espace de travail ne contient aucune modification non validée avant le build de référence.

02

Choisir la chaîne d’outils

Utilisez xcode-select -p et xcodebuild -version pour consigner le répertoire développeur actuel et la version de Xcode.

03

Vérifier les paramètres de signature

Vérifiez l’équipe du projet, l’identifiant de bundle, le nom de configuration et le mode de signature. Anonymisez d’abord les détails des certificats présents dans les logs.

04

Créer l’archive

Indiquez explicitement le workspace ou project, le scheme, la configuration et archivePath, puis conservez le code de sortie complet et les logs.

05

Télécharger les artefacts

Une fois l’archive terminée, vérifiez la taille du fichier, sa somme de contrôle et le répertoire d’export, puis copiez les artefacts vers l’emplacement sécurisé convenu avec l’équipe.

Commande de référence du build Utilisez des alias pour les valeurs sensibles 
git rev-parse HEAD
xcode-select -p
xcodebuild -version
xcodebuild -workspace "<WORKSPACE>" \
  -scheme "<SCHEME>" \
  -configuration Release \
  -archivePath "<OUTPUT>/App.xcarchive" \
  archive | tee "<LOG_DIR>/archive.log"

Validation de la réussite

Le code de sortie est 0, le répertoire d’archive existe, la taille de l’artefact est conforme et les logs ne contiennent aucune erreur ignorée de signature ou de script.

Orienter l’échec

Déterminez successivement s’il concerne la résolution des dépendances, la compilation, l’édition des liens, la signature, les scripts ou l’export, au lieu de résumer tout problème par « échec du build Xcode ».

Fournir les preuves

Fournissez le hash du commit, la version de Xcode, la commande exécutée, le code de sortie, l’étape en échec et un extrait de logs anonymisé ; n’envoyez ni clé privée ni identifiants complets.

Automatisation CI/CD

Délimiter chaque exécution du runner auto-hébergé

Les pipelines GitHub, GitLab et autres peuvent router les tâches macOS vers des nœuds dédiés. L’environnement d’exécution n’est pas partagé avec d’autres locataires, mais votre équipe doit toujours gérer la concurrence, les caches et le nettoyage.

Concurrence

Commencer par une référence à tâche unique

Vérifiez d’abord qu’un pipeline passe entièrement, puis augmentez progressivement la concurrence. Plusieurs builds écrivant simultanément dans le même DerivedData, trousseau ou répertoire de sortie risquent de se polluer mutuellement.

  • Utilisez un répertoire de travail distinct pour chaque tâche.
  • Ajoutez l’identifiant de la tâche aux chemins des simulateurs et des archives.
  • Consignez les pics de CPU, de mémoire et d’utilisation disque ainsi que le temps d’attente.
Cache

Chaque cache doit avoir une clé vérifiable

La clé du cache des dépendances doit au moins contenir le résumé du fichier de verrouillage, la version de la chaîne d’outils et l’architecture. Même après un succès du cache, vérifiez l’intégrité des dépendances : un ancien cache ne garantit pas un résultat correct.

  • Gérez séparément le cache des dépendances et les artefacts intermédiaires de build.
  • Générez activement une nouvelle clé de cache après un changement de chaîne d’outils.
  • Consignez les temps de succès, de repli et de reconstruction du cache.
Nettoyage

Récupérer l’état temporaire à la fin de la tâche

Exécutez une phase de nettoyage, que la tâche réussisse ou échoue. Conservez les logs et artefacts à rapatrier, puis supprimez les clés temporaires, répertoires de travail et états de simulateur inutilisés.

  • Utilisez finally ou un mécanisme équivalent pour le nettoyage.
  • Archivez d’abord les logs d’échec, puis supprimez le répertoire de travail.
  • Contrôlez régulièrement l’espace disque occupé et les caches obsolètes.
  1. 01 Enregistrer l’exécuteur

    Intégrez le runner avec des informations d’enregistrement temporaires contrôlées par l’équipe ; les étiquettes doivent indiquer clairement Apple Silicon, la région et le workflow prévu.

  2. 02 Établir une tâche de référence

    Exécutez uniquement la vérification de l’environnement et un build minimal, puis confirmez que les droits du dépôt, le chemin Xcode, le téléchargement des dépendances et le retour des artefacts fonctionnent.

  3. 03 Ajouter le cache

    Mesurez d’abord la durée sans cache, puis créez la clé à partir du fichier de verrouillage et de la chaîne d’outils afin de pouvoir vérifier son efficacité réelle.

  4. 04 Valider le nettoyage

    Provoquez volontairement un échec et vérifiez que les logs sont toujours rapatriés, que les informations temporaires sont révoquées et que les tâches suivantes n’héritent pas de l’état précédent.

Stockage et Thunderbolt 5

Confirmez les options dans la commande, puis vérifiez la capacité et la liaison après livraison

La configuration de base est Debug M4 : M4, 16GB de RAM, SSD 256GB. Les SSD +1TB, +2TB et la mise en parallèle Thunderbolt 5 sont des options distinctes ; leur présence ne peut pas être déduite de l’affichage système.

Stockage additionnel

+1TB SSD

Facturation selon la commande
Par jour$2.3
Par semaine$6.1
Par mois$11.3
Par trimestre$30.7

Avant l’activation, confirmez le workflow cible, le pic prévu et la méthode de migration des données ; après livraison, vérifiez la capacité totale, le nom du volume, le système de fichiers et le chemin de montage.

Stockage additionnel

+2TB SSD

Facturation selon la commande
Par jour$4.6
Par semaine$12.2
Par mois$22.6
Par trimestre$61.4

Convient aux tâches nécessitant de conserver davantage d’archives, de médias ou de fichiers de modèles. Validez la capacité à partir des informations disque du système et du montage réel.

Facturation par machine

Mise en parallèle Thunderbolt 5

Calcul séparé par machine
Par jour$1.7
Par semaine$4.6
Par mois$8.5
Par trimestre$23.1

Avant l’envoi, précisez le nombre d’unités en parallèle, la répartition des tâches et l’emplacement de regroupement des artefacts. Cette option est facturée par machine ; le prix d’une machine ne permet pas de déduire celui du groupe.

  1. 01 Vérifier la commande

    Confirmez le nom et le nombre d’options, la durée de location et le montant en USD. L’état réellement disponible et la passerelle de paiement sont ceux renvoyés en temps réel par le panneau.

  2. 02 Vérifier le système

    Utilisez diskutil list et df -h pour consigner les disques, volumes et espaces disponibles, au lieu de vous fier uniquement aux icônes du bureau.

  3. 03 Tester la lecture-écriture

    Effectuez un petit test de lecture-écriture dans le répertoire de travail cible afin de confirmer les droits, le chemin et l’emplacement réel des artefacts ; un test extrême unique ne représente pas les performances à long terme.

  4. 04 Consigner les correspondances

    Lors d’une collaboration entre plusieurs disques ou machines, consignez la relation « tâche — volume — répertoire d’artefacts » afin d’éviter qu’un nettoyage supprime des données à conserver.

Manuel de diagnostic réseau

Quatre groupes de tests pour distinguer réseau local, liaison interrégionale et session du nœud

Une seule mesure de latence ou une seule déconnexion ne suffit pas à localiser le problème. Répétez les mesures sur le même réseau et à des heures proches, en conservant la commande, la cible, l’heure et la sortie brute.

Commandes de diagnostic réseau, observations et limites d’interprétation
Test Commande d’exemple Points à observer Distinction possible
Latence de base ping -c 20 <HOST> Perte de paquets, variations, emplacement des dépassements de délai consécutifs Anomalie d’accès local et anomalie persistante de la liaison
Suivi de route traceroute <HOST> Changements de route, sauts anormaux, persistance des dépassements de délai Sortie locale, route interrégionale et liaison proche de la cible
Contrôle du port nc -vz <HOST> 22 Connexion réussie, refusée ou expirée Hôte joignable mais port SSH inaccessible
Test de transfert scp <FILE> <USER>@<HOST>:<PATH> Débit constant, nouvelles tentatives, somme de contrôle du fichier Problèmes de latence interactive et de transfert de gros fichiers
Contrôle de session ssh -vv <USER>@<HOST> Résolution, négociation, sélection de clé, phase d’authentification Problèmes de réseau, d’empreinte, de clé et de configuration utilisateur

Problème de réseau local

Plusieurs cibles sont anormales depuis le même appareil, la situation revient à la normale sur un réseau contrôlé ou des pertes persistantes apparaissent dans les premiers sauts de la sortie locale. Indiquez le type de réseau et le résultat d’une nouvelle mesure.

Problème de liaison interrégionale

L’accès local est normal, mais une route précise présente des variations persistantes. Fournissez plusieurs suivis de route ; un saut intermédiaire silencieux ne signifie pas nécessairement une perte réelle de paquets.

Problème de session du nœud

L’hôte et le port sont accessibles, mais l’authentification, le shell ou la session graphique échoue. Conservez alors la sortie SSH détaillée, l’erreur de session et les opérations récentes.

Cadre d’interprétation des tests

Les résultats réseau dépendent de l’opérateur local, du mode d’accès, de la route interrégionale et de l’heure de mesure. Ils servent uniquement à délimiter le problème et ne constituent pas un engagement de performance. Tous les nœuds fonctionnent normalement 365 jours par an ; vérifiez la disponibilité dans les relevés de service réels.

Checklist de préparation du ticket

Préparer la demande d’assistance pour une transmission reproductible

Pour un problème sur un nœud en service, envoyez en priorité un ticket depuis le panneau. Avant-vente ou accès impossible : écrivez à support@debugmac.com. Les deux canaux utilisent la même liste d’informations.

  1. 01 Identifiant de commande

    Fournissez l’identifiant affiché dans le panneau et le modèle Debug M4 ; n’envoyez ni justificatif de paiement, ni clé privée, ni mot de passe d’accès complet.

  2. 02 Région du nœud

    Indiquez Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong ou Ouest des États-Unis, et précisez si le problème apparaît uniquement dans cette région.

  3. 03 Heure de survenue

    Indiquez l’heure de la première occurrence avec son fuseau, l’heure de la dernière reproduction et la durée ; évitez « à l’instant » ou « parfois ».

  4. 04 Étapes de reproduction

    Présentez les entrées, la commande exécutée, le résultat attendu et le résultat réel. Si la reproduction n’est pas stable, indiquez sa fréquence et les conditions communes observées.

  5. 05 Logs anonymisés

    Conservez les horodatages, codes de sortie et contexte de l’erreur ; retirez les clés, jetons, mots de passe, adresses de dépôts internes et autres valeurs sensibles.

  6. 06 Vérifications déjà effectuées

    Listez les commandes exécutées, le nombre de tentatives, les changements de réseau et les résultats afin d’éviter que l’assistance répète les mêmes contrôles de base.

Nœuds et comptes en service

Se connecter au panneau pour envoyer un ticket

Le ticket peut être associé à la commande, au nœud et à l’historique de traitement ; il convient aux problèmes de connexion, de build, de stockage, de facturation et d’accès au compte.

Accéder au panneau
Avant-vente ou accès impossible

Envoyer un e-mail d’assistance structuré

Indiquez dans l’objet le type de tâche et la région du nœud ; structurez le corps selon la checklist de cette page. L’unique adresse d’assistance externe est support@debugmac.com.

Envoyer l’e-mail d’assistance
Prêt à commencer

Besoin d’un Mac dans le cloud à la configuration vérifiable ?

Choisissez Debug M4, la durée de location et l’un des cinq sites, puis revérifiez avant l’envoi la configuration de base, les options, la région et le montant dû en USD. L’état réellement disponible est celui renvoyé en temps réel par le panneau.

Louer un Mac dans le cloud Voir la configuration et les tarifs