Bei Verbindungsproblemen prüfen Sie zuerst Gerätestatus und Zugangsdaten, bei Build-Fehlern Xcode, Abhängigkeiten und Signierung. CDNMac stellt dedizierte physische Macs bereit, keine virtuellen Maschinen. Projektcode, Entwicklerkonten und Signierungsressourcen verwalten Sie selbst.
Halten Sie bei bestehenden Bestellungen möglichst Bestellnummer, ausgewählten Standort, Zeitpunkt und bereinigte Logs bereit. Maßgeblich sind der aktuelle Gerätestatus und die in der Konsole verfügbaren Aktionen.
Halten Sie fest, ob ein einzelnes Gerät, ein Repository, ein Build oder alle Verbindungsarten betroffen sind.
Prüfen Sie Netzwerk, Systemzugriff, Toolchain, Projektabhängigkeiten und Signierung einzeln. Ändern Sie nicht mehrere Einstellungen gleichzeitig.
Senden Sie bereinigte Logs, das erwartete Ergebnis und bereits getestete Schritte. Übermitteln Sie keine privaten Schlüssel, Tokens, Zertifikatpasswörter oder vollständigen Zahlungsdaten.
Ordnen Sie das Problem nach dem Hauptsymptom ein und halten Sie die passenden Informationen bereit. Beschränken Sie jede Anfrage auf ein Hauptproblem; weitere Symptome können Sie in den Reproduktionsschritten ergänzen.
Notieren Sie den Gerätestatus in der Konsole, die genaue SSH- oder VNC-Fehlermeldung, Ihr lokales Netzwerk, den Zeitpunkt des ersten Auftretens und ob nur eine Verbindungsart betroffen ist.
Geben Sie die Versionen von Xcode und Command Line Tools, die verwendete Lockdatei, den fehlgeschlagenen Befehl, das Ziel-Scheme, den freien Speicherplatz und den ersten aussagekräftigen Fehler im Log an.
Senden Sie die bereinigte Signierungsfehlermeldung, die Bundle-ID, die Zielumgebung und den Gültigkeitsstatus des Zertifikats. Keine Zertifikatpasswörter, privaten Schlüssel oder verwendbaren Tokens übermitteln.
Notieren Sie den Internetanbieter, den Netzwerktyp, den Zielstandort und den Median mehrerer aufeinanderfolgender Messungen. Prüfen Sie auch, ob Repository-Abrufe oder Downloads von Abhängigkeiten betroffen sind.
Geben Sie Bestellnummer, Mietdauer, Basiskonfiguration und die Bezeichnung gebuchter SSD- oder Thunderbolt-5-Verbindungen an. Vollständige Zahlungsdaten gehören nicht ins Ticket.
Notieren Sie den aktuellen Standort, die gewünschte Verbindungsrichtung sowie Arbeitsverzeichnisse und Build-Artefakte, die erhalten bleiben sollen. Geben Sie an, ob die Umgebung neu eingerichtet werden darf. Welche Optionen verfügbar sind, sehen Sie aktuell in der Konsole.
Schließen Sie jeden Schritt ab und notieren Sie das Ergebnis, bevor Sie fortfahren. Tauschen Sie nicht gleichzeitig Schlüssel aus, ändern Sie die Firewall nicht und starten Sie das lokale Netzwerk nicht neu – sonst lässt sich die Ursache kaum feststellen.
Prüfen Sie Bestellung und Gerätestatus in der Konsole und vergleichen Sie Standort und Gerätekennung. Ändert sich der Status gerade, warten Sie auf eine stabile Anzeige, bevor Sie die Verbindung testen.
Verwenden Sie den Systembenutzernamen, Hostnamen und die aktuellen Zugangsdaten des betreffenden Geräts. Vermischen Sie keine Verbindungsdaten verschiedener Bestellungen.
Testen Sie aus einem vertrauenswürdigen Netzwerk, ob Host und Port erreichbar sind. Prüfen Sie anschließend Dateiberechtigungen des Schlüssels und Authentifizierungsfehler. Sichern Sie die Fehlermeldung mit Zeitstempel, aber übermitteln Sie niemals den privaten Schlüssel.
Funktioniert SSH, aber die grafische Sitzung nicht, notieren Sie separat VNC-Client, Verbindungsphase und Bildschirmanzeige. So lässt sich ein Sitzungsproblem von einem grundlegenden Netzwerkfehler unterscheiden.
Prüfen Sie, ob Unternehmensnetzwerk, VPN, ausgehende Verbindungsregeln oder lokale Firewall den Zielport blockieren. Testen Sie gegebenenfalls ein anderes vertrauenswürdiges Netzwerk, um die lokale Verbindung als Ursache einzugrenzen.
Ein einzelner Ping zeigt nur die Netzwerk-Rundlaufzeit zu diesem Zeitpunkt. Er sagt nichts Verlässliches über die VNC-Darstellung, Downloadgeschwindigkeit von Abhängigkeiten oder die gesamte Build-Dauer aus. Prüfen Sie mehrere Messwerte und testen Sie reale Aufgaben.
Build-Logs enthalten oft Folgefehler. Suchen Sie zuerst den ersten aussagekräftigen Fehler, der den Ablauf unterbricht. Prüfen Sie anschließend die zugehörigen Tools, Abhängigkeiten, Signierung oder Speicherbedingungen.
Notieren Sie die vollständige Xcode-Version, Zielplattform, Scheme, Configuration und den tatsächlich verwendeten Toolpfad. Grafische Oberfläche und Befehlszeile sollten dieselbe Version nutzen.
Prüfen Sie, ob das ausgewählte Entwicklerverzeichnis und die erwartete Version übereinstimmen. Kontrollieren Sie nach einem Xcode-Upgrade, auf welchen Pfad die Kommandozeilenwerkzeuge verweisen, damit Skripte nicht eine alte Version aufrufen.
Behalten Sie die im Projekt verwendete Lockdatei bei und notieren Sie den Befehl zur Wiederherstellung der Abhängigkeiten sowie die Cache-Einstellungen. Testen Sie zuerst in einem sauberen Arbeitsverzeichnis, bevor Sie eine beschädigte Cache-Datei als Ursache annehmen.
Prüfen Sie, ob Gültigkeitsstatus, Bundle-ID, Zielumgebung und Signierungseinstellungen zusammenpassen. Übermitteln Sie nur bereinigte Fehlermeldungen, keine privaten Schlüssel oder Zertifikatpasswörter.
Berücksichtigen Sie gemeinsam den Speicherbedarf von Quellcode, Dependency-Caches, DerivedData, Archiven und exportierten Builds. Bei Platzmangel können Sie zuerst wiederherstellbare Cache-Dateien löschen.
Halten Sie Startzeit, ersten Fehler und Endzeit fest. Geben Sie an, ob der Fehler beim Wiederherstellen von Abhängigkeiten, Kompilieren, Archivieren, Signieren oder Exportieren auftrat.
CDNMac M4 kann iOS-Builds aus Repository-Ereignissen ausführen. Bei der Anbindung an GitHub Actions, GitLab CI, Jenkins oder andere Systeme sollte der Runner als dauerhaft verfügbarer Build-Host behandelt werden, nicht als kurzlebiger Container.
Anhand von Repository, Branch und Runner-Labels entscheiden, ob der Job ausgeführt wird.
Lockdatei und Repository-spezifischen Cache verwenden; Cache-Treffer protokollieren.
Xcode-Pfad, Scheme, Configuration und Exportparameter festlegen.
Benötigte Artefakte kopieren, temporäre Verzeichnisse löschen und bereinigte Diagnose-Logs aufbewahren.
Einheitliche Begriffe im Support-Ticket erleichtern die Unterscheidung zwischen physischem Gerät, Zugriffsprotokoll, Automatisierungs-Runner und ausgelieferten Dateien.
Ein vollständiger Kontext erleichtert die Reproduktion mehr als mehrere kurze Nachrichten. Bei vertraulichen Daten nennen Sie nur Art und Status – niemals verwendbare Klartextinhalte.
Geben Sie Bestell- oder Gerätekennung aus der Konsole an, damit Modell, Mietdauer und Gerät zugeordnet werden können.
Nennen Sie den aktuellen Gerätestandort, nicht nur „Asien“ oder „USA“. Falls ein Wechsel nötig ist, geben Sie zusätzlich die gewünschte Verbindungsrichtung an.
Notieren Sie das erste Auftreten, die letzte Reproduktion und das Ende des Vorgangs samt Zeitzone. So lassen sich passende Geräte- und Netzwerkprotokolle finden.
Beschreiben Sie Eingaben, Befehle, Ziel und Ergebnis der Reihe nach. Tritt das Problem nicht immer auf, geben Sie Häufigkeit und Auslöser an.
Behalten Sie Fehlerkontext und Zeitstempel bei. Entfernen Sie private Schlüssel, Tokens, Zertifikatpasswörter, personenbezogene Daten und vollständige Zahlungsdaten.
Beschreiben Sie den erwarteten Status, die Datei oder den Rückgabewert und nennen Sie bereits getestete, erfolglose Schritte.
Unterscheiden Sie zwischen Gerät und Netzwerk, Systemzugriff, Empfehlungen zur Toolchain und Verantwortlichkeiten Ihres Projekts. So vermeiden Sie wiederholte Änderungen auf der falschen Ebene.
Wir prüfen Gerätestatus, Netzwerk am Standort, Bestellzuordnung und in der Konsole sichtbare Verwaltungsinformationen. Mit nachvollziehbaren Angaben können wir den Fall weiter untersuchen.
Unterstützung durch CDNMacWir helfen festzustellen, ob das Gerät erreichbar ist, die Zugangsdaten zum Gerät gehören und ob SSH- oder VNC-Probleme auf Netzwerk-, Authentifizierungs- oder Sitzungsebene auftreten.
Unterstützung durch CDNMacAnhand von Logs können wir Xcode, Command Line Tools, Speicherplatz und Build-Phasen gemeinsam prüfen. Projektabhängigkeiten und Skripte muss Ihr Team selbst validieren.
Gemeinsame FehlerbehebungProjektcode, Entwicklerkonten, Zertifikate, Profile, Zugriffsschlüssel, Softwarelizenzen, Abhängigkeitsversionen und die zulässige Nutzung der Arbeitslast verwaltet Ihr Team selbst.
Verantwortung Ihres TeamsEin dediziertes Gerät verringert die gemeinsame Nutzung von Ressourcen, ersetzt aber nicht das Berechtigungsmanagement Ihres Teams. Für die erste Verbindung, den laufenden Betrieb und das Mietende sollte es jeweils eine klare Checkliste geben.
Vergeben Sie CI-Tokens, Repository-Schlüsseln und Automatisierungskonten nur die für den jeweiligen Job nötigen Rechte. Verwenden Sie nicht dieselben weitreichenden Zugangsdaten dauerhaft für mehrere Projekte.
Dokumentieren Sie die Erneuerung von Schlüsseln und Tokens. Entziehen Sie nicht mehr benötigte Zugriffsrechte umgehend, wenn sich Teammitglieder, Repositories oder Jobgrenzen ändern.
Prüfen Sie regelmäßig Zertifikate und Profile auf ihre Gültigkeit und löschen Sie nicht mehr benötigte Kopien. So verhindern Sie, dass Pipelines versehentlich alte Einstellungen verwenden.
Kopieren Sie Änderungen am Quellcode, Build-Logs, Archive und erforderliche Artefakte vor Mietende in einen vom Team verwalteten Speicher. Prüfen Sie, ob sich die Dateien öffnen lassen.
Geben Sie Bestellnummer, Standort, Zeitpunkt, Reproduktionsschritte, bereinigte Logs und erwartetes Ergebnis an. Senden Sie keine Schlüssel, Tokens oder Zertifikatpasswörter im Klartext.