Von den Zugangsdaten bis zu Xcode, Signierung und Continuous Integration: Finde die passenden Schritte für deine Aufgabe. Jeder Check liefert ein überprüfbares Ergebnis und hilft dir, bei Problemen eine reproduzierbare Diagnose zu erstellen.
Physischer Apple-Silicon-Knoten: Deine Bestellung umfasst ein exklusiv zugewiesenes Gerät, keine virtuelle Maschine. Prüfe vor der ersten Verbindung Knoten, Systemversion und Zugangsart.
Du musst nicht alles von Anfang an lesen. Wähle deine aktuelle Aufgabe und öffne direkt die passende Checkliste. Bestellung, Verlängerung und Gerätestatus gehören ins Portal; technische Konfiguration und Fehleranalyse erledigst du auf dieser Seite.
Zugangsdaten abrufen, Netzwerk, Auflösung und Zwischenablage prüfen und anschließend die Wiederverbindung nach einem Abbruch testen.
Verbindungsschritte ansehen ToolchainXcode-Version, Zertifikate, Provisioning-Profile, Keychain-Berechtigungen und Einstellungen für die automatische Signierung prüfen.
Entwicklungsumgebung prüfen Automatisierungself-hosted Runner bereitstellen, Arbeitsverzeichnisse planen und Abhängigkeiten sowie Build-Cache kontrollieren.
Runner bereitstellen SystemprüfungVor Upgrades oder Änderungen an der Toolchain den Umgebungsstatus dokumentieren, Kompatibilität prüfen und Wiederherstellungsunterlagen vorbereiten.
Upgrade-Strategie ansehen PortalaufgabenBestellungen, Verlängerungen, Geräteinformationen, Zugangsdaten und Ticketverläufe bearbeiten.
Portal öffnenBeim ersten Zugriff geht es nicht darum, sofort alle Projekte zu migrieren. Prüfe zunächst, ob Zugangsdaten, Netzwerk, grafische Sitzung und SSH stabil funktionieren. Starte keine langen Builds, bevor die grundlegende Verbindung bestätigt ist.
Bestellkennung, Knoten, Gerätename und Zugangsart prüfen. Zugangsdaten ausschließlich in einem kontrollierten Passwortmanager speichern und nicht über Gruppenchats oder öffentliche Dokumente weitergeben.
Sicherstellen, dass das lokale Netzwerk die benötigten Ports nicht blockiert. Temporäre Proxys deaktivieren, die Routen ändern könnten, und aktuellen öffentlichen Ausgang sowie Testzeit dokumentieren. Zuerst über ein stabiles kabelgebundenes Netzwerk testen, danach die WLAN-Leistung vergleichen.
Zunächst eine Auflösung verwenden, die dem lokalen Monitor nahekommt, und Lesbarkeit, Tastenbelegung sowie bidirektionale Zwischenablage prüfen. Hohe Auflösungen erhöhen bei schwachem Netzwerk die Belastung durch Bildschirmaktualisierungen; Stabilität bei der Interaktion hat Vorrang.
Eine Sitzung absichtlich trennen und erneut verbinden. Prüfen, ob laufende Befehle weiterlaufen und die grafische Sitzung auf dem ursprünglichen Desktop wiederhergestellt wird. Lange Aufgaben am besten in einer persistenten Terminsitzung oder einem CI/CD-Job ausführen.
Zugriffsrechte nur an erforderliche Mitglieder vergeben und Zugangsdaten bei Teamänderungen sofort aktualisieren. Private Schlüssel, vollständige Passwörter und Codes zur Fernsteuerungsbestätigung niemals in Skripten, Repositories, Build-Logs oder Screenshots speichern.
Zuerst die SSH-Sitzung bestätigen, dann einen Xcode-Build ausführen und zuletzt das Automatisierungstool für die Paketierung prüfen. Die Beispiele zeigen nur den Prüfpfad; Projektname, Scheme, Workspace und Exportparameter müssen durch die Teamkonfiguration ersetzt werden.
$ ssh developer@assigned-mac
connection established
$ sw_vers -productVersion
current macOS version returned
$ xcodebuild -workspace App.xcworkspace \
-scheme App -configuration Release build
Resolve Package Graph
CompileSwiftSources normal arm64
** BUILD SUCCEEDED **
$ bundle exec fastlane ios verify_build
Checking signing assets
Archive validation passed
fastlane finished successfullyDie meisten Signierungsfehler werden nicht durch einen einzelnen Schalter verursacht. Zuerst Toolversionen festlegen, dann die Übereinstimmung von Zertifikaten und Provisioning-Profilen prüfen und abschließend sicherstellen, dass der Automatisierungsprozess auf die benötigten Keychain-Einträge zugreifen kann.
Xcode-Version der grafischen Oberfläche und Pfad der Kommandozeilentools gemeinsam dokumentieren. Bei mehreren Versionen muss das Build-Skript die Auswahl explizit treffen, damit Sitzung und Runner nicht unterschiedliche Toolchains verwenden.
$ xcodebuild -version
$ xcode-select -p
$ xcrun --find swiftZertifikate, private Schlüssel und Provisioning-Profile müssen zum selben Signierungsprozess gehören. Nach dem Import zunächst Gültigkeit, Teaminformationen und Bundle Identifier prüfen; ein offizieller Build sollte nicht der erste Test sein.
Was in der grafischen Sitzung funktioniert, ist nicht automatisch für den Automatisierungsprozess verfügbar. Unter dem Runner-Benutzer und in einer nicht interaktiven Umgebung Entsperrverfahren, Suchliste und Berechtigungen für den Code-Signaturzugriff prüfen.
Fehlgeschlagenen Befehl, Zielnamen, Configuration, Exportmethode und erste Fehlerzeile aufbewahren. Nicht nur die letzte allgemeine Fehlermeldung einreichen – sie enthält meist nicht die eigentliche Ursache.
| Prüfobjekt | Zu dokumentieren | Erfolgskriterium | Nächster Schritt bei Fehlern |
|---|---|---|---|
| macOS | Aktuelle Version, verfügbarer Speicherplatz | Ziel-Xcode wird eindeutig unterstützt | Änderung stoppen und Kompatibilitätsmatrix prüfen |
| Xcode | Version, Auswahlpfad, SDK | Kommandozeile und grafische Oberfläche stimmen überein | Toolpfad korrigieren und Minimal-Build erneut ausführen |
| Signierungsmaterial | Zertifikatsstatus, Provisioning-Profil, Team | Bundle Identifier und Exportmethode stimmen überein | Erneut importieren und Keychain-Berechtigungen prüfen |
| Projektabhängigkeiten | Lock-Datei, Laufzeit, Plugin-Versionen | Installation in sauberem Verzeichnis ist reproduzierbar | Lokalen Cache bereinigen und Fehler-Logs aufbewahren |
Der Runner sollte nicht direkt das tägliche Entwicklungsverzeichnis wiederverwenden. Trenne Repository, Abhängigkeits-Cache, Build-Artefakte und temporäre Dateien, damit ein fehlgeschlagener Job den nächsten Build nicht beeinträchtigt.
Jedes Repository separat halten, temporäre Dateien nach Abschluss des Jobs entfernen und keine Checkout-Verzeichnisse unbekannter Herkunft wiederverwenden.
Cache-Schlüssel anhand von Lock-Datei oder Toolversion erzeugen; bei Versionsänderungen gezielt invalidieren statt bedingungslos alles wiederzuverwenden.
Artefakte getrennt vom Quellcode speichern und lokale Kopien nach erfolgreichem Upload gemäß Teamrichtlinie bereinigen.
Plattformbasierten Secret-Mechanismus zur Injektion verwenden und Logausgaben begrenzen; nichts in Projektdateien, Cache oder Archiven speichern.
VMOwn-Knoten sind 365 Tage im Jahr normal in Betrieb. Systemupgrades sind aktive Änderungen durch den Nutzer. Wähle einen Zeitraum ohne Auswirkungen auf Releases und Builds und prüfe vorher die Kompatibilität der Toolchain.
Vor dem Upgrade einen reproduzierbaren Build, Test und Archivierungslauf abschließen und Commit-Version sowie Ergebnis dokumentieren. Nach dem Upgrade mit denselben Eingaben erneut ausführen – nur so lassen sich Abweichungen sinnvoll eingrenzen.
Letzten erfolgreichen und ersten fehlgeschlagenen Schritt dokumentieren; nicht wiederholt den gesamten Cache löschen. Toolversionen, Fehler-Logs und Reproduktionsbefehl zusammenstellen und als Ticket einreichen.
„Verbindung fehlgeschlagen“ oder „Build-Fehler“ reicht für die Analyse nicht aus. Bitte Kontext, exakten Zeitpunkt, ersten Fehler und minimale Reproduktionsschritte angeben und vertrauliche Inhalte aus den Logs entfernen.
Den tatsächlich verwendeten Knoten aus Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong oder dem Westen der USA sowie die Bestellkennung aus dem Portal angeben.
Versionen von macOS, Xcode, Kommandozeilentools und direkt relevanten Abhängigkeiten dokumentieren; eine vollständige Softwareliste des Geräts ist nicht nötig.
Zeitpunkt, Dauer und Zeitzone des Problems angeben. Bei Verbindungsproblemen außerdem Standort und Typ des lokalen Netzwerks nennen.
Den erforderlichen Kontext vor und nach dem Fehler bewahren und bevorzugt die erste Fehlermeldung einreichen – nicht nur den letzten Exit-Status.
Mit einem bekannten funktionierenden Zustand beginnen und Befehle, Oberflächenaktionen, Eingaben und tatsächliche Ergebnisse der Reihe nach aufführen.
Angeben, ob die Verbindung erneut hergestellt, ein Job neu gestartet, das Netzwerk gewechselt, ein lokaler Cache bereinigt oder eine Konfiguration zurückgesetzt wurde, damit der Zustand nicht durch Wiederholungen verändert wird.
Fragen vor dem Kauf und allgemeine technische Fragen kannst du an support@vmown.com richten. Bei bestehenden Bestellungen bitte bevorzugt im Portal ein Ticket einreichen, damit Gerät, Knoten und Bestellung zugeordnet werden können.