Praxisorientierter Engineering-Support

Vom Verbinden mit dem Cloud Mac bis zur Auslieferung der Build-Artefakte – Probleme Schritt für Schritt lösen

Dies ist keine Konzeptdokumentation. Jede Anleitung enthält Voraussetzungen, Schritte, Prüfergebnisse und die bei Fehlern aufzubewahrenden Logs. Für SSH, VNC-Remote-Desktop, Xcode, fastlane, selbst gehostete Runner und Abrechnung.

Im Control Panel ein Ticket erstellen Anleitungsindex ansehen
4 Anleitungseinstiege 5 Servicestandorte 365 Tage verfügbar
build-diagnostics Prüfung bestanden
Verbindungsmethoden SSH / VNC
Build-Tools Xcode / fastlane
Ausführungsarchitektur Apple Silicon
$ xcodebuild -version Xcode 16.x $ uname -m arm64 $ df -h / volume check: ready
Erst die Umgebung prüfen, dann die vollständige Pipeline ausführen So lässt sich die Fehlerursache auf Verbindung, Abhängigkeiten, Signierung oder Konkurrenz eingrenzen.
Support-Center durchsuchen

Nach Aufgabe filtern – nicht alles von Anfang an lesen

Wählen Sie die aktuelle Aufgabe oder suchen Sie nach Begriffen wie SSH, Archiv, Signierung, Runner, Standort oder Abrechnung. Der Filter ändert nur die Indexkarten; die vollständigen Schritte bleiben weiter unten auf dieser Seite.

Aufgabenkategorien

9 Anleitungen anzeigen

Geräte verbinden

Erste Verbindung per SSH und VNC

Öffentlichen Schlüssel vorbereiten, Host-Fingerabdruck prüfen, die arm64-Umgebung kontrollieren und die grafische Sitzung anschließend sicher beenden.

Voraussichtlich 10 Minuten Entwicklungsumgebung einrichten

Xcode auswählen und Abhängigkeiten installieren

Toolchain-Versionen festlegen, den Pfad der Kommandozeilentools prüfen und Ruby-, Pods- oder Swift-Package-Abhängigkeiten anhand der Lock-Datei wiederherstellen.

Voraussichtlich 15 Minuten Builds ausführen

Archiv erstellen und Artefakte exportieren

Das Archiv mit explizitem Workspace, Scheme und Destination erstellen und xcresult sowie Export-Logs sichern.

Voraussichtlich 20 Minuten Builds ausführen

fastlane-Automatisierung und Bereinigung

Sensible Variablen nur kurzfristig injizieren, die festgelegte Lane ausführen und temporäre Dateien sowie die Prozessumgebung nach dem Sichern der Artefakte entfernen.

Voraussichtlich 20 Minuten Builds ausführen

Selbst gehosteten Mac Runner anbinden

Einen dedizierten Runner registrieren, den Repository-Bereich begrenzen, Capability-Tags festlegen und das Arbeitsverzeichnis nach jedem Auftrag bereinigen.

Voraussichtlich 25 Minuten Entwicklungsumgebung einrichten

Fünf-Punkte-Checkliste bei Build-Fehlern

Netzwerk, Speicher, Signiermaterial, Abhängigkeits-Cache und Parallelität nacheinander prüfen; nicht mehrere Variablen gleichzeitig ändern.

Voraussichtlich 15 Minuten Geräte verbinden

Standort auswählen und Migration beantragen

Einen von fünf Standorten anhand der Position von Entwicklern, Code-Repository und Pipeline-Diensten auswählen und die Migration per Ticket beantragen.

Voraussichtlich 5 Minuten Abrechnung verwalten

Bestellung und Zusatzoptionen prüfen

Bestellkennung, Mietzeitraum, Standort sowie Speicher- oder Thunderbolt-5-Verbundoption angeben, damit der Abrechnungseintrag gefunden werden kann.

4 Angaben vorbereiten Abrechnung verwalten

Support durch Mitarbeitende anfordern

Gerätekennung, Standort, Zeitraum und bereinigte Logs über ein Control-Panel-Ticket oder die Support-E-Mail senden.

Zwei Kontaktwege
Verbindungsanleitung

Zuerst eine vertrauenswürdige Verbindung herstellen, dann die Umgebung einrichten

Maßgeblich sind die Verbindungsdaten im Control Panel. Private Schlüssel, Einmal-Zugangsdaten oder vollständige Verbindungsbefehle nicht in öffentliche Repositories, Build-Logs oder Team-Chats einfügen.

SSH-Verbindung über die Kommandozeile

  1. 1
    Öffentlichen Schlüssel des lokalen Geräts vorbereiten

    Verwenden Sie vorzugsweise einen separaten, passwortgeschützten Schlüssel. Laden Sie nur den öffentlichen Schlüssel hoch; private Schlüssel niemals per Ticket oder E-Mail senden.

  2. 2
    Verbindungsdaten abrufen

    Gerätekennung, Standort, Hostadresse, Port und Benutzernamen im Control Panel prüfen, damit keine alten Mietdaten verwendet werden.

  3. 3
    Host-Fingerabdruck verifizieren

    Vor der ersten Verbindung den im Control Panel angezeigten Fingerabdruck vergleichen. Bei Abweichungen die Verbindung abbrechen und ein Ticket erstellen; den lokalen Eintrag nicht einfach überschreiben.

  4. 4
    Grundlegende Prüfungen durchführen

    Führen Sie uname -m,xcodebuild -version und df -h /aus und protokollieren Sie Architektur, Toolchain und verfügbaren Speicher.

VNC-Remote-Desktop-Verbindung

  1. 1
    Zuerst SSH-Verfügbarkeit bestätigen

    Wenn die grafische Verbindung fehlschlägt, ist SSH der wichtigste Weg, Prozesse, Speicher und Netzwerkstatus zu prüfen. Verifizieren Sie zuerst den Host-Fingerabdruck.

  2. 2
    Sitzungsdaten aus dem Control Panel abrufen

    Verwenden Sie den VNC-Zugang und die temporären Zugangsdaten des aktuellen Geräts. Speichern Sie sie nicht in Browser-Synchronisierung, gemeinsam genutzten Dokumenten oder Pipeline-Variablen.

  3. 3
    Grafische Umgebung prüfen

    Nach der Anmeldung Auflösung, Tastaturlayout, Xcode-Status und verfügbaren Speicher prüfen, bevor Signierung oder Archivierung beginnt.

  4. 4
    Sitzung beenden und bereinigen

    Laufende Entwicklungstools schließen, temporäre Downloads und Klartext-Zugangsdaten entfernen und anschließend die Remote-Desktop-Sitzung beenden.

Grenzen der Zugangsdatenverwaltung: Teammitglieder sollten jeweils eigene, kontrollierte Zugangswege verwenden. Beim Ausscheiden eines Mitglieds den zugehörigen öffentlichen Schlüssel und Pipeline-Token widerrufen – nicht nur die lokale SSH-Konfiguration ändern.
Xcode-Build-Anleitung

Versionen, Abhängigkeiten und Exportparameter eindeutig festlegen – nur so sind Builds reproduzierbar

Nicht auf das zuletzt in der grafischen Oberfläche gewählte Scheme vertrauen. Automatisierte Aufgaben müssen Xcode-Pfad, Workspace, Scheme, Configuration, Destination und Exportkonfiguration explizit angeben.

01

Xcode-Version auswählen und prüfen

Lesen Sie zuerst die Projektanforderungen und richten Sie anschließend mit xcode-select die Zielversion ein. Führen Sie danach jeweils xcodebuild -version und xcrun swift --versionaus und schreiben Sie die Ausgabe an den Anfang des Build-Logs.

02

Abhängigkeiten anhand der Lock-Datei installieren

Führen Sie in Ruby-Projekten zuerst bundle installaus; stellen Sie Pods-Projekte anhand der Lock-Datei wieder her und lösen Sie bei Swift Packages zunächst die Abhängigkeiten auf. Caches beschleunigen nur – sie ersetzen nicht die Versionsvorgaben der Lock-Datei.

03

Archivierungsaufgabe ausführen

DerivedData und archivePath auf separate Verzeichnisse der aktuellen Aufgabe richten. Parallele Aufgaben dürfen denselben Ausgabepfad nicht gemeinsam nutzen, damit Indizes, Caches und Archive nicht überschrieben werden.

04

Artefakte exportieren und prüfen

Mit einer versionskontrollierten Exportkonfiguration exportieren. Exit-Code, Artefaktdateien, Signierergebnis und dSYM prüfen und die Artefakte anschließend in ein kontrolliertes Auslieferungsverzeichnis kopieren.

05

Nachvollziehbare Logs sichern

Mindestens die Textausgabe des Builds, Export-Logs und xcresult sichern. Dateinamen sollten die Kennung der Pipeline-Aufgabe enthalten, aber keine Zugriffstoken, privaten Schlüssel oder vollständigen Signiermaterialien.

archive.sh 
xcode-select -p
xcodebuild -version
xcrun swift --version

bundle install
bundle exec pod install

xcodebuild archive \
  -workspace App.xcworkspace \
  -scheme App \
  -configuration Release \
  -destination "generic/platform=iOS" \
  -archivePath output/App.xcarchive \
  -resultBundlePath output/App.xcresult

xcodebuild -exportArchive \
  -archivePath output/App.xcarchive \
  -exportPath output/export \
  -exportOptionsPlist ExportOptions.plist
Eingaben Repository, Lock-Datei, kontrollierte Umgebungsvariablen Ausführungsort Dedizierter Cloud Mac Ausgabe Archiv, Exportdateien, xcresult, bereinigte Logs
Anleitung zur fastlane-Automatisierung

Sensible Variablen nur während der Aufgabe verfügbar

fastlane soll Build-Schritte orchestrieren, nicht Schlüssel dauerhaft speichern. Signiermaterial, Repository-Token und Upload-Zugangsdaten über kontrollierte Variablen injizieren und nach Abschluss der Aufgabe bereinigen.

INPUT

Schlüssel und Signierkonfiguration injizieren

Beim Start der Aufgabe nur Variablen mit minimalem Umfang injizieren. Temporäre Dateien in ein aufgabenspezifisches Verzeichnis legen, Dateirechte beschränken und Variablenwerte nicht durch Befehlsausgaben offenlegen.

  • Variablennamen dürfen protokolliert werden, ihre Werte nicht
  • Signierkonfiguration eindeutig dem Projekt-Branch zuordnen
  • Temporäre Verzeichnisse dürfen von späteren Aufgaben nicht wiederverwendet werden
RUN

Festgelegte Lane ausführen

Verwenden Sie bundle exec fastlane mit festen Ruby- und gem-Versionen. Die Lane muss Scheme, Exportmethode, Ausgabeverzeichnis und Abbruchbedingungen bei Fehlern eindeutig festlegen.

  • Tool-Versionen vor dem Build ausgeben, aber keine Zugangsdaten
  • Aktuelle Aufgaben-Logs und xcresult bei Fehlern aufbewahren
  • Vor einem erneuten Versuch zuerst Umgebungs- oder Codefehler unterscheiden
CLEAN

Artefakte sichern und bereinigen

Archive, Exportdateien und Logs zuerst an einen kontrollierten Ort kopieren, dann temporäre Signierdateien, Umgebungsdateien, Download-Caches und das Arbeitsverzeichnis entfernen.

  • Prüfen, ob Artefakte vorhanden sind und eine plausible Dateigröße haben
  • Sensible Befehle aus der Shell-Historie entfernen
  • Sicherstellen, dass keine Build-Prozesse im Hintergrund zurückbleiben
bundle exec fastlane ios archive Feste Abhängigkeitsversionen Separates Ausgabeverzeichnis Bei Fehlern ungleich null zurückgeben
Anleitung zur CI/CD-Integration

Den Cloud Mac als kontrollierten Ausführungsknoten in die Pipeline integrieren

Der Runner muss an einen klar definierten Repository- oder Projektbereich gebunden sein. Aufgaben aus nicht vertrauenswürdigen Branches dürfen nicht automatisch Produktions-Signiermaterial erhalten; Aufgaben mit unterschiedlichen Sicherheitsstufen dürfen kein Arbeitsverzeichnis teilen.

GitHub Actions

Ablauf zur Einbindung eines selbst gehosteten Runners

  1. Geltungsbereich festlegen

    Je nach Berechtigungsmodell einen Repository- oder organisationsweiten Runner wählen und die aufrufenden Projekte begrenzen.

  2. Dedizierten Systembenutzer anlegen

    Der Runner-Prozess darf kein alltägliches Administratorkonto verwenden. Nur die für Arbeitsverzeichnis und Build-Tools nötigen Rechte vergeben.

  3. Capability-Tags festlegen

    Tags sollten Architektur, Xcode-Hauptversion und Aufgabentyp angeben, damit Workflows den passenden Knoten auswählen.

  4. Serielle oder parallele Strategie konfigurieren

    Ein Arbeitsverzeichnis darf gleichzeitig nur eine Aufgabe verarbeiten. Für Parallelität separate Verzeichnisse oder Geräte verwenden.

  5. Nach jeder Aufgabe bereinigen

    Temporäre Variablendateien, Signiermaterial und nicht hochgeladene Artefakte löschen, zurückgebliebene Prozesse prüfen und erst dann die nächste Aufgabe annehmen.

Gängige Pipeline-Systeme

Über einen Agenten oder SSH-Executor anbinden

  1. Einseitigen Aufgabeneingang einrichten

    Die Pipeline weist Aufgaben dem Cloud Mac zu; Geräteverwaltungsdaten nicht in der Repository-Konfiguration hinterlegen.

  2. Befehle und Verzeichnisse begrenzen

    Der Build-Benutzer darf nur auf festgelegte Repositories, Caches und Ausgabepfade zugreifen; Administrationsaufgaben laufen über einen separaten Berechtigungsweg.

  3. Toolchain vorab prüfen

    Vor dem regulären Build Architektur, Xcode, Ruby, Abhängigkeitsmanager und verfügbaren Speicher prüfen. Bei fehlgeschlagener Vorprüfung Aufgabe stoppen.

  4. Einheitliche Exit-Codes

    Fehler bei Installation, Tests, Archivierung oder Export müssen einen Exit-Status ungleich null liefern, damit die Pipeline keinen Erfolg vortäuscht.

  5. Erst nach dem Upload bereinigen

    Nach dem Upload von Artefakten und Logs das Aufgabenverzeichnis bereinigen. Die Aufgabenkennung zur Ticket-Zuordnung aufbewahren.

Empfehlung für Parallelität:Die Basisstufe mit M4, 16GB und 256GB eignet sich für leichte Builds und die Signierung einzelner Projekte. Die Pro-Stufe mit M4 Pro, 64GB und 2TB ist besser für hochparallele Builds und große Abhängigkeits-Caches geeignet. Entscheidend sind Spitzen-RAM, Zahl paralleler Aufgaben und Cachegröße.
Checkliste zur Fehlerdiagnose

Pro Durchgang nur eine Variable ausschließen

Zuerst Aufgabenkennung und Zeitraum des Fehlers notieren, dann Netzwerk, Speicher, Signierung, Cache und Parallelität in dieser Reihenfolge prüfen. Jede Prüfung dokumentieren, statt die Umgebung wiederholt neu zu installieren.

So prüfen Sie Netzwerk- und Verbindungs-Timeouts

Zuerst prüfen, ob das lokale Netzwerk den Geräteport erreicht, danach DNS, Proxy, SSH-Host-Fingerabdruck und Systemzeit kontrollieren. Aufbauzeit, Trennzeit und vollständigen Fehlertext separat dokumentieren. Wenn SSH funktioniert, VNC aber nicht, den Prozess der grafischen Sitzung prüfen und nicht zuerst die gesamte Entwicklungsumgebung zurücksetzen.

ssh -v user@host
Zu wenig Speicher oder fehlgeschriebene Archivierung

Verwenden Sie df -h / um den verfügbaren Speicher zu prüfen; kontrollieren Sie anschließend DerivedData, Abhängigkeits-Caches, alte Archive und Simulatordaten. Große Verzeichnisse zuerst identifizieren und nur eindeutig wiederherstellbare Caches löschen. Verzeichnisse, die ein laufender Build verwendet, nicht bereinigen.

du -sh ~/Library/Developer/*
Signierzertifikat oder Konfiguration passt nicht

Projektkennung, Build-Konfiguration, Exportmethode, Zertifikatsgültigkeit und Zuordnung des Provisioning-Profils prüfen. Sicherstellen, dass die Pipeline die für die aktuelle Aufgabe benötigten Materialien injiziert, und die Systemzeit kontrollieren. In Logs Fehlertyp und Zuordnung beibehalten, Zertifikatsinhalte, private Schlüssel und Token ausblenden.

security find-identity -v -p codesigning
Abhängigkeits-Cache verursacht Versionsabweichungen oder Build-Fehler

Zuerst Lock-Datei und tatsächlich verwendete Versionen im Log vergleichen. Einen Build in einem neuen Aufgabenverzeichnis ohne gemeinsamen Cache ausführen; verschwindet das Problem, Swift-Package-, Pods-, Ruby- und DerivedData-Caches schrittweise wieder aktivieren, um die Ursache zu finden.

swift package resolve
Ressourcenkonflikte durch parallele Builds

Gleichzeitig laufende xcodebuild-, Test- und Abhängigkeitsprozesse sowie die Ausgabeverzeichnisse aller Aufgaben prüfen. Parallelität reduzieren und erneut testen; Spitzen-RAM, Datenträgerzugriffe und Laufzeit beobachten. Mehrere Aufgaben dürfen archivePath, resultBundlePath oder temporäre Signierverzeichnisse nicht gemeinsam nutzen.

ps -axo pid,%cpu,%mem,command
Standorte und Verfügbarkeit

Alle fünf Standorte unterstützen zwei Klassen dedizierter physischer Macs

Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong und die US-Ostküste sind 365 Tage im Jahr verfügbar. Kombinationen im Katalog sind üblicherweise buchbar; maßgeblich ist die Echtzeitverfügbarkeit im Control Panel.

Katalog und Auswahlhilfe für die zwei MiniRents-Modelle an fünf Standorten
Standort Teamstandort, der bevorzugt berücksichtigt werden sollte MiniRents M4 MiniRents M4 Pro Auswahlempfehlung
SingapurSG Teams in Südostasien und nahe gelegene Code-Repositories Ausreichend Ausreichend Zuerst die Verbindungsstabilität zwischen Entwicklern und Standort sowie zwischen Repository und Standort vergleichen.
Japan (Tokio)JP Teams in Japan und Ostasien Ausreichend Ausreichend Geeignet für Workflows, deren Repositorys und Mitarbeitende überwiegend in Ostasien liegen.
Südkorea (Seoul)KR Teams in Südkorea und im angrenzenden Ostasien Ausreichend Ausreichend Vor der Auswahl die SSH-Stabilität aus dem tatsächlichen Büronetz testen.
HongkongHK Kooperationsteams in Südchina und Südostasien Ausreichend Ausreichend Geeignet für Teams, die mehrere asiatische Arbeitsstandorte berücksichtigen müssen.
US-OstküsteUS-E Teams an der nordamerikanischen Ostküste und in Westeuropa Ausreichend Ausreichend Geeignet für Workflows, deren Repository, Artefaktdienst oder Hauptmitglieder nahe der US-Ostküste liegen.
01

Interaktive Verbindung zuerst prüfen

Bei häufiger VNC-Nutzung ist die Stabilität zwischen Entwicklern und Standort entscheidend; bei ausschließlich automatisierter Pipeline-Ausführung sind die Positionen von Repository und Artefaktdienst wichtiger.

02

Datenfluss anschließend prüfen

Abhängigkeitsdownloads, Repository-Abrufe und Artefakt-Uploads belasten die Verbindung. Hauptdatenquellen und Ausführungsknoten auf eine stabilere Route legen.

03

Migration per Ticket beantragen

Aktuelle Gerätekennung, aktuellen Standort, Zielstandort, gewünschten Zeitraum und Migrationsgrund angeben. Ergebnis und weitere Schritte richten sich nach dem Ticket im Control Panel.

Support durch Mitarbeitende anfordern

Wenn die Anleitung nicht weiterhilft, eine reproduzierbare Problembeschreibung einreichen

Technische Probleme vorzugsweise über ein Control-Panel-Ticket melden, damit Gerät und Bestellung verknüpft werden können. Bei fehlendem Control-Panel-Zugriff oder Fragen zu Pre-Sales, Abrechnung, Sicherheit und Team-Rollout eine E-Mail senden.

Control-Panel-Ticket

Geeignet für Verbindungsabbrüche, Gerätestatus, Build-Umgebung, Standortmigration sowie Bestell- und Abrechnungsfragen. Das Ticket mit aktuellem Gerät oder Auftrag verknüpfen und reproduzierbare Informationen angeben.

  • Gerätekennung und aktueller Standort
  • Zeitraum des Problems
  • Ausgeführte Schritte und erwartetes Ergebnis
  • Vollständiger Fehlertext und bereinigte Logs
  • Bereits abgeschlossene Prüfungen
Im Control Panel ein Ticket erstellen

Support-E-Mail

Geeignet bei fehlendem Control-Panel-Zugriff, zur Pre-Sales-Konfigurationsbewertung, für Team-Rollouts, Sicherheitsberichte und allgemeine Fragen. Problemtyp im Betreff nennen und Passwörter, private Schlüssel sowie vollständige Token aus dem Text fernhalten.

  • Name und geschäftliche E-Mail-Adresse
  • Beratungstyp und gewünschter Workflow
  • Gewünschter Standort und Build-Parallelität
  • Reproduktionsschritte und Auswirkungsbereich des Sicherheitsberichts
  • Bestellkennung und Zusatzoptionen bei Abrechnungsfragen
support@minirents.com
Abrechnungsinformationen

Bei Abrechnungsfragen vier Angaben nennen

Bestellkennung, Mietzeitraum, Standort sowie Speichererweiterung oder Thunderbolt-5-Verbund angeben. Unterstützt werden ausschließlich USDT-TRC20 und Visa / Mastercard / Amex (über Stripe); alle Gebühren werden in US-Dollar (USD) abgerechnet. Maßgeblich ist das vom Backend gemeldete verfügbare Gateway.

Bereit für den Build

Dedizierten Cloud Mac wählen und die erste Pipeline erfolgreich ausführen

Zwei Modellklassen, vier Mietzeiträume und fünf Standorte zur Auswahl. Dedizierte physische Macs statt virtueller Maschinen, Einstiegspreis $21.5/Tag.

Cloud Mac jetzt mieten Tarife und Preise ansehen