Von der Abnahme bis zum stabilen Betrieb

Ihren Cloud-Mac in den Build-Workflow integrieren

Prüfen Sie nach Erhalt der Gerätedaten zunächst Bestellung und physischen Node. Richten Sie anschließend Verbindung, reproduzierbare Toolchain und CI-Runner ein. Jeder Schritt enthält Prüfkommandos, Erfolgskriterien und zu sichernde Nachweise.

Cloud-Mac jetzt mieten Konfigurationen und Preise ansehen

Verfügbare Nodes: 5physische Nodes
Verfügbare Konfigurationen: 2dedizierte physische Macs
Vorgehensweise: 9Prüfschritte

Übergabe-Checkliste für die erste Verbindung Der Reihe nach prüfen

Übergabedaten prüfen

Node, Konfiguration, Systemversion, Mietdauer und Zugangsdaten müssen mit der Auftragsbestätigung übereinstimmen.

Abnahme

Erste Sitzung einrichten

Prüfen Sie zuerst die CLI-Verbindung. Richten Sie anschließend nach Bedarf eine GUI-Sitzung ein und testen Sie die Wiederherstellung nach einer Unterbrechung.

Verbindung

Entwicklungsumgebung reproduzieren

Fixieren Sie Xcode, Abhängigkeiten und Arbeitsverzeichnis, statt das alte Gerät vollständig zu kopieren.

Konfiguration

Einen echten Build ausführen

Führen Sie mit dem echten Repository eine Archivierung oder einen Testlauf aus und dokumentieren Sie Dauer, Logs und Artefaktprüfung.

Validierung

Vorbereitung

Zuerst Gerät, Node und Mietdauer bestätigen

Beginnen Sie erst mit der Migration, wenn alle Angaben geprüft sind. Melden Sie sich an der Konsole an und vergleichen Sie Bestellung und Gerätedetails. Bei Abweichungen sichern Sie die Seiteninformationen und erstellen ein Ticket.

Node und Netzwerkpfad

Bestätigen Sie, dass der Node in Singapur, Tokio, Seoul, Hongkong oder an der US-Ostküste steht. Notieren Sie den Node-Code und testen Sie den Verbindungspfad aus dem wichtigsten Büronetzwerk.

Hauptzugriffsorte des Teams und Zeitzone des Nodes bestätigen
Büro- und Ersatznetzwerk getrennt testen
Latenz, Jitter und Paketverlust erfassen, statt nur einen einzelnen Ping zu betrachten

Gerätekonfiguration

Das Angebot umfasst zwei Stufen. Prüfen Sie nach Erhalt der Daten Chip, Arbeitsspeicher und Speicher Feld für Feld.

Basis: M4, 16 GB, 256 GB
Hochleistung: M4 Pro, 64 GB, 2 TB
Zusätzlicher Speicher richtet sich nach der Auftragsbestätigung

System- und Zugangsdaten

Prüfen Sie Systemversion, Hostname, Verbindungsadresse, Port und temporäre Zugangsdaten. Wechseln Sie die Zugangsdaten nach der ersten Anmeldung gemäß Teamstandard.

Passwörter oder private Schlüssel nicht in öffentliche Logs einfügen
Zugangsdaten in einem kontrollierten Secrets-Management-Tool speichern
Bestätigen, welche Daten CLI- und GUI-Verbindungen jeweils benötigen

Mietdauer und Endzeit

Legen Sie bei Tages-, Wochen-, Monats- oder Quartalsmiete vor Beginn den Zeitpunkt für den Datenexport und den Aufgabenstopp fest, damit die Bereinigung nicht bis zum Schluss warten muss.

Beginn und Ende der Mietdauer dokumentieren
Zeit für Artefaktexport und Cache-Bereinigung einplanen
Intern verantwortliche Person für Verlängerung oder Anpassung bestimmen

Leitfaden für die erste Verbindung

Zuerst per CLI die Erreichbarkeit prüfen, dann eine GUI-Sitzung einrichten

Die CLI eignet sich für grundlegende Abnahmen und Automatisierung, die GUI-Sitzung für Xcode, Simulatoren und visuelle Aufgaben. Prüfen Sie beide Wege getrennt; eine erfolgreiche Verbindung bedeutet nicht, dass alles funktioniert.

CLI-Verbindung

Eine minimal überprüfbare Sitzung einrichten

1
Zieldaten prüfen
Hostadresse, Port und Benutzernamen aus der Konsole kopieren, Zeichen sowie Groß-/Kleinschreibung prüfen und keine veralteten Angaben aus alten Tickets verwenden.
2
Host-Fingerprint prüfen
Vergleichen Sie ihn bei der ersten Verbindung mit den Übergabedaten. Bei einer Änderung Verbindung stoppen und Ursache klären; nicht einfach den lokalen Eintrag löschen und erneut versuchen.
3
Nur-Lese-Prüfung ausführen
Aktuellen Benutzer, Hostname, Systemversion, Laufwerke und Xcode-Pfad bestätigen; zunächst keine Software installieren oder entfernen.
4
Wiederherstellung nach Unterbrechung prüfen
Verbindung absichtlich trennen und erneut herstellen. Prüfen Sie Sitzungswiederherstellung, Strategie für lange Aufgaben und Log-Verzeichnis.

Remote-GUI-Zugriff

Bildqualität und Aufgabenstabilität getrennt prüfen

1
Mit moderater Bildqualität beginnen
Zunächst mit niedrigerer Auflösung und Farbqualität die Sitzungsstabilität prüfen, dann Einstellungen schrittweise erhöhen. So wird Ruckeln nicht fälschlich als Leistungsproblem des Geräts bewertet.
2
Zugangsdaten und Zwischenablage schützen
Passwörter, private Schlüssel und Zertifikatspasswörter dürfen nicht in geteilten Bildschirmen, Aufzeichnungen oder unkontrollierten Zwischenablagen sichtbar sein.
3
Sitzung ohne Aufsicht sperren
Sperren Sie die GUI-Sitzung, bevor Sie das Gerät verlassen. Bei Zusammenarbeit muss jederzeit klar sein, wer Änderungen vornimmt.
4
Status nach der Wiederverbindung prüfen
Nach einer Wiederverbindung prüfen, ob Vordergrund-Apps, Build-Prozesse und Schreibvorgänge noch laufen. Ein eingefrorenes Bild bedeutet nicht automatisch, dass die Aufgabe fehlgeschlagen ist.

Schnellprüfung im Terminal

Mit einer Gruppe schreibgeschützter Befehle eine Gerätebasis erstellen

Die folgenden Befehle prüfen Chip, Arbeitsspeicher, Speicher, Systemversion, Netzwerk und Entwicklerpfade. Ausgabe speichern, vor einem Ticket jedoch Benutzernamen, interne Repository-Adressen und andere vertrauliche Felder entfernen.

DPLYMAC / FIRST-RUN CHECK

printf '\n== CHIP ==\n'
system_profiler SPHardwareDataType | grep -E "Chip|Memory"

printf '\n== DISK ==\n'
diskutil info / | grep -E "Device Node|File System|Disk Size|Free Space"

printf '\n== SYSTEM ==\n'
sw_vers
uname -m

printf '\n== NETWORK ==\n'
route -n get default | grep interface
ping -c 5 1.1.1.1

printf '\n== XCODE ==\n'
xcodebuild -version
xcode-select -p
swift --version

printf '\n== TOOL PATHS ==\n'
command -v git
command -v ruby
command -v fastlane

Woran erkenne ich eine erfolgreiche Prüfung?

Chip und Arbeitsspeicher entsprechen der bestellten Konfiguration
Root-Volume ist les- und beschreibbar, freier Speicher reicht für die Aufgabe
Systemarchitektur gibt arm64 aus
Standard-Netzwerkschnittstelle ist vorhanden, kontinuierlicher Test zeigt keinen deutlichen Paketverlust
Xcode und CLI-Toolpfade zeigen auf die erwarteten Versionen

Was muss aufbewahrt werden?

Ausführungszeit der Befehle und Node
Vollständige Befehle, nicht nur die letzte Zeile
Originalausgabe und bereinigte Ticketfassung
Erwartetes Ergebnis, tatsächliches Ergebnis und Anzahl der Reproduktionen

Xcode und Signierumgebung

Toolchain fixieren, dann benötigte Build-Materialien importieren

Konsistenz entsteht durch klare Versionen und reproduzierbare Schritte, nicht durch das vollständige Kopieren des alten Benutzerverzeichnisses. Signiermaterial nur im erforderlichen Umfang importieren und vor Mietende bereinigen.

Prüfpunkt Aktion Erfolgskriterium

Xcode-Version

Ausführen xcodebuild -version, Hauptversion und Build-Nummer dokumentieren; bei fester Projektversion die Anforderung in der Repository-Dokumentation festhalten.

Version entspricht den Projektanforderungen

CLI-Tools

Ausführen xcode-select -p, bei Bedarf auf einen vom Team freigegebenen Pfad umschalten; während der Aufgabe kein spontanes Upgrade durchführen.

Pfad zeigt auf das Ziel-Xcode

Zertifikate importieren

Nur für das aktuelle Projekt benötigte Zertifikate importieren, kontrolliert übertragen und den Schlüsselbundzugriff begrenzen.

Ziel-Signieridentität ist erkennbar

Provisioning-Profile

App-ID, Teamdaten, Capabilities und Gültigkeit prüfen; keine Altdateien anderer Projekte verwenden.

Archivierungsziel entspricht der Projektkonfiguration

Schlüsselbund entsperren

Im Build-Skript nur für die erforderliche Mindestdauer entsperren, danach wieder sperren. Passwörter nicht in Repository oder gewöhnliche Logs schreiben.

Nichtinteraktiver Build kann erforderliche Elemente lesen

Prüfung vor dem Build

Vor der vollständigen Archivierung Abhängigkeitsauflösung, Projektliste und Signiereinstellungen prüfen.

Fehler tritt vor dem eigentlichen Build auf

Migrationsablauf

Migration in drei Übergaben aufteilen: Daten, Toolchain und Runner

Ändern Sie jeweils nur eine Variable und bewahren Sie einen Rücksetzpunkt. So lässt sich bei Build-Abweichungen unterscheiden, ob Daten, Abhängigkeiten oder die CI-Registrierung ursächlich sind.

Übergabe 01

Datensynchronisierung

Eingabe: Quellcode, benötigte Ressourcen, Lock-Dateien für Abhängigkeiten und Build-Skripte
Aktion: Vorrangig aus dem Repository abrufen; große Dateien separat prüfen, irrelevante Caches und alte Artefakte nicht kopieren
Prüfung: Commit-Version, Dateianzahl und Prüfsummen entsprechen den Erwartungen; keine sensiblen Dateien im Repository
Häufige Fehler: Dateien durch unvollständige Ignore-Regeln, Unterschiede bei Groß-/Kleinschreibung, geänderte Zeilenenden oder verlorene Berechtigungsbits
Rücksetzpunkt: Sauberes Arbeitsverzeichnis behalten; Synchronisationsdaten löschen und erneut abrufen können

Übergabe 02

Toolchain reproduzieren

Eingabe: Xcode-Anforderungen, Abhängigkeitsliste, Paket-Lock-Dateien und Laufzeitversionen der Skripte
Aktion: Nach Dokumentation den minimalen Werkzeugsatz installieren, Versionen fixieren und Pfade sowie Umgebungsvariablen explizit in der Aufgabenkonfiguration festlegen
Prüfung: Abhängigkeiten werden erfolgreich aufgelöst; derselbe Commit liefert lokal und in Automatisierung identische Ergebnisse
Häufige Fehler: Implizite globale Abhängigkeiten, abweichendes Standard-Ruby, falscher Xcode-Pfad, verunreinigter Cache
Rücksetzpunkt: Versionsliste und Installationslogs aufbewahren; Tool-Cache leeren und erneut reproduzieren können

Übergabe 03

CI-Integration

Eingabe: Runner-Registrierungsdaten, Warteschlangen-Tags, Arbeitsverzeichnis, Cache-Regeln und Parallelitätslimit
Aktion: Einen Runner registrieren, zunächst eine schreibgeschützte Prüfung ausführen und danach eine vollständige Pipeline mit einem echten Repository starten
Prüfung: Aufgabe wird korrekt geplant; Exit-Code, Logs, Testergebnisse und Artefakte sind nachvollziehbar
Häufige Fehler: Nicht passende Tags, wiederverwendete Arbeitsverzeichnisse, zu breite Cache-Schlüssel, mehrere Aufgaben konkurrieren um dieselbe Ressource
Rücksetzpunkt: Runner abmelden und zu manuellen Builds zurückkehren, ohne bereits geprüfte Daten oder Toolchain zu beeinträchtigen

CI/CD-Integration

Ein registrierter Runner bedeutet noch keine zuverlässige Pipeline

Nach der Registrierung mindestens je eine Aufgabe mit kaltem und warmem Cache sowie einen fehlgeschlagenen Wiederholungsversuch prüfen. Arbeitsverzeichnis, Cache und Parallelität müssen von der Pipeline ausdrücklich verwaltet werden.

Prüfung gängiger CI-Runner-Integrationen
Plattform	Registrierungsprüfung	Arbeitsverzeichnis	Caching-Strategie	Empfehlung zur Parallelität
GitHub Actions	Self-hosted-Runner-Tags und Ziel-Repository bzw. Organisationsbereich bestätigen	Jede Aufgabe nutzt einen eigenen Workspace; temporäre Dateien danach löschen	Cache-Schlüssel enthalten Lockfile-Hash sowie Xcode- und Architekturinformationen	Mit einer Aufgabe prüfen, dann Parallelität nach Speicher- und Festplattenlast erhöhen
GitLab CI	Runner-Tags, Rechte geschützter Branches und Runner-Status prüfen	Keine beschreibbaren Verzeichnisse oder gleichnamigen Artefaktpfade zwischen Projekten teilen	Cache-Bereich nach Projekt, Branch und Abhängigkeits-Hash trennen	Separate Warteschlangen für Archivierung, Tests und leichte Prüfungen einrichten
Jenkins	Node-Tags, Remote-Root-Verzeichnis und Gültigkeitsbereich der Zugangsdaten bestätigen	Workspace nach Pipeline-Ende bereinigen, notwendige Logs jedoch behalten	Abhängigkeits-Cache und Build-Artefakte getrennt verwalten	Gleichzeitige Nutzung eines Geräts durch schwere Archivierungsaufgaben begrenzen
Eigener Runner	Dienststart, Laufzeitbenutzer und Bedingungen für die Aufgabenübernahme dokumentieren	Verzeichnisse nach Aufgaben-ID anlegen und beim Beenden deterministisch bereinigen	Cache-Eigentümer, Kapazitätsgrenze und Ungültigkeitsbedingungen festlegen	Ressourcen über eine Warteschlange steuern, nicht auf zufälliges Locking durch Skripte vertrauen

Registrierung abgeschlossen

Runner ist online, Tags stimmen, Laufzeitbenutzer ist korrekt und Zugriff besteht nur auf freigegebene Repositories und Zugangsdaten.

Aufgabe reproduzierbar

Derselbe Commit erzeugt mit kaltem und warmem Cache identische Artefakte; bei Fehlern bleibt ein eindeutiger Exit-Code erhalten.

Verzeichnisse bereinigbar

Temporäre Signierdateien, Derived Data und Build-Zwischendateien folgen festen Bereinigungsregeln, ohne manuelles Löschen.

Parallelität begrenzt

Warteschlangen nach CPU-, Speicher- und SSD-Last dimensionieren, damit Archivierungsaufgaben Ressourcen nicht gegenseitig verdrängen.

Performanceanalyse

Zuerst die betroffene Schicht bestimmen, dann Parameter anpassen

Dokumentieren Sie mindestens Zeitpunkt, Node, Commit, Reproduktionsschritte und Vergleichsergebnis. „Sehr langsam“ unterscheidet weder Ressourcenlast noch Netzwerkpfad oder GUI-Probleme.

CPU

Dauerhafte Berechnung oder kurzfristige Spitze unterscheiden

Prozesse mit hoher Auslastung, Thread-Anzahl und Aufgabenphase erfassen. Einzel- und Parallelaufgaben vergleichen und doppelte Builds, ausufernde Tests oder Hintergrundindizierung prüfen.

Prozess-Sampling

Arbeitsspeicher

Speicherdruck und Swap-Aktivität prüfen

Spitzenverbrauch, komprimierten Speicher und Swap-Änderungen dokumentieren. Scheitert die Aufgabe nur parallel, zuerst Parallelität senken und erneut vergleichen, statt sofort das Netzwerk verantwortlich zu machen.

Lastvergleich

SSD

Kapazitätsmangel und Engpässe bei zufälligen Lese-/Schreibzugriffen unterscheiden

Freien Speicher, Derived Data, Abhängigkeits-Cache und alte Artefakte prüfen. Vor der Bereinigung Verzeichnisgrößen dokumentieren, damit Beweise nicht verloren gehen.

Kapazität und I/O

Netzwerk

Latenz, Jitter, Paketverlust und Durchsatz vergleichen

Mit einem festen lokalen Netzwerk kontinuierlich testen und mit einem Ersatznetzwerk vergleichen. Bei langsamen Repository-Abrufen zusätzlich Node-Pfad und Antwort des Abhängigkeitsdienstes unterscheiden.

Kontinuierliche Messung

GUI-Sitzung

Ruckelnde Darstellung bedeutet nicht, dass der Build-Prozess langsamer ist

Nach Reduzierung von Auflösung und Farbqualität erneut testen und per CLI prüfen, ob die Aufgabe weiterläuft. Vorder- und Hintergrundstatus nach der Wiederverbindung dokumentieren.

Sitzungstrennung

Sicherheit und Beendigung

Ab der ersten Anmeldung die abschließende Übergabe vorbereiten

Für Zugangsdaten, Signiermaterial, Build-Artefakte und Caches muss jeweils ein Eigentümer feststehen. Vor Mietende der Reihe nach exportieren, prüfen, entfernen und erneut kontrollieren.

Kontinuierliche Ausführung

Zugangsdaten und Berechtigungen

Temporäre Zugangsdaten nach der ersten Verbindung wechseln
Minimal erforderliche Rechte nach Repository und Aufgabe vergeben
Geltungsbereich von Runner- und Automatisierungsschlüsseln regelmäßig prüfen
Passwörter nicht in Skripten, Repositories oder gewöhnlichen Logs speichern

Vor dem Export

Artefakte und Daten

Archive, Testberichte und erforderliche Logs exportieren
Dateianzahl und Prüfsummen am Zielort kontrollieren
Bestätigen, dass Repository-Commit und Remote-Branch synchron sind
Noch benötigte Build-Baseline dokumentieren

Vor Mietende

Umgebung bereinigen

CI-Runner abmelden und verbundene Zugangsdaten widerrufen
Zertifikate, Provisioning-Profile, private Schlüssel und Wiederherstellungscodes entfernen
Arbeitsverzeichnisse, temporäre Dateien und sensible Caches löschen
Download-Ordner, Schreibtisch und Befehlshistorie erneut prüfen

Support

Das Ticket von Anfang an reproduzierbar machen

Bei Problemen mit bestehenden Bestellungen melden Sie sich an der Konsole an und erstellen Sie ein Ticket. Wenn die Anmeldung nicht möglich ist, senden Sie eine E-Mail an support@deploymac.com. Entfernen Sie vor dem Absenden Passwörter, private Schlüssel, Zertifikatspasswörter und andere vertrauliche Zugangsdaten.

Vorlage für Fehlerberichte Felder kopieren, keine vertraulichen Daten

Bestellkennung

Kennung aus der Konsole zur Zuordnung der Bestellung eintragen

Node

Singapur, Tokio, Seoul, Hongkong oder US-Ostküste

Zeitpunkt

Zeitzone sowie Zeitpunkt des ersten Auftretens und der letzten Reproduktion angeben

Gerätekonfiguration

Basis- oder Hochleistungsstufe sowie Angaben zum zusätzlichen Speicher

Reproduktionsschritte

Mit einem sauberen Zustand beginnen und die tatsächliche Reihenfolge vollständig aufführen

Befehlsausgabe

Vollständige Befehle, Exit-Code und bereinigte Ausgabe anhängen, nicht nur Screenshots

Erwartetes Ergebnis

Normal erwarteten Status, Dateien oder Rückgabewert beschreiben

Tatsächliches Ergebnis

Abweichung, Reproduktionsanzahl und Auswirkungen auf alle Aufgaben angeben

Bereits getestete Maßnahmen

Wiederholungen, Wiederverbindungen, geringere Parallelität oder Cache-Bereinigung samt Ergebnis auflisten

Bestehende Bestellung und Verbindungsfehler

Konsolen-Tickets können Bestellung, Node und Gerätedaten zuordnen und eignen sich für Übergabeprüfung, Verbindungs- und Betriebsprobleme.

Ticket in der Konsole erstellen

Noch nicht bestellt oder Anmeldung nicht möglich

Geben Sie in der E-Mail Zweck, Ziel-Node, geplante Mietdauer und Auswirkungsbereich an. Senden Sie niemals Passwörter, private Schlüssel oder Zertifikatspasswörter.

Support-E-Mail senden

Nächster Schritt

Konfiguration nach Aufgabenlast wählen, dann die erste Verbindung einrichten

Die Basisstufe eignet sich für leichte Builds und die tägliche Entwicklung; die Hochleistungsstufe für speicherintensive Experimente, parallele Projekte und anspruchsvollere Builds. Beide Stufen sind dedizierte physische Macs und keine virtuellen Maschinen.

Cloud-Mac jetzt mieten Die zwei Optionen vergleichen