Diese Checkliste beginnt mit der Auswahl und prüft anschließend Standort, Zugangsdaten, Toolchain, Signaturumgebung und Build-Artefakte. Ziel ist nicht nur ein erreichbarer Rechner, sondern ein reproduzierbarer, rücksetzbarer Build mit vollständigen Logs auf einem exklusiven physischen Mac mini.
Singapur
Japan (Tokio)
Südkorea (Seoul)
Hongkong
Westliche USA
Ein falscher Standort oder fehlende Repository-Berechtigungen kosten meist mehr Zeit als die Installation der Tools. Tragen Sie die folgenden Angaben vor der Bestellung in das Team-Ticket ein; Verantwortliche, Prüfverfahren und Rückfallweg müssen eindeutig feststehen.
Prüfen Sie, ob die für Signierung und Veröffentlichung verantwortlichen Personen über die erforderlichen Berechtigungen verfügen. Legen Sie außerdem fest, wer Zertifikate, Provisioning-Profile und Teamkennung verwaltet. Sensible Authentifizierungsdaten gehören nicht in normale Chatverläufe oder Build-Logs.
Abnahmekriterium Die verantwortliche Person kann Herkunft, Gültigkeitsbereich und Erneuerungsprozess der Signaturmaterialien erläutern.Prüfen Sie Haupt-Repository, Submodule, private Paketquellen, Artefakt-Repository und Large-File-Speicher einzeln. Maschinenzugänge für CI müssen von persönlichen Zugangsdaten getrennt sein und nur die für den Build nötigen Minimalrechte erhalten.
Abnahmekriterium In einer sauberen Umgebung lassen sich vollständiger Quellcode und exakt gesperrte Abhängigkeiten abrufen.Leiten Sie die Xcode-Version aus Projektkonfiguration, Ziel-SDK, Compileranforderungen und Plugin-Kompatibilität ab. Bei mehreren Release-Zweigen dokumentieren Sie Xcode- und Command-Line-Tools-Version je Zweig.
Abnahmekriterium Versionsnummer, Auswahlgrund und Kompatibilitätstest sind dokumentiert.Verfügbar sind Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong und die westlichen USA. Berücksichtigen Sie vor allem Codequelle, Dependency-Mirror und das Netzwerk der Nutzer – nicht nur die geografische Entfernung.
Abnahmekriterium Der Zielstandort wurde aus den wichtigsten Büronetzwerken getestet und die Netzwerkmessung dokumentiert.Ermitteln Sie die maximale Belegung durch Quellcode, Dependency-Cache, DerivedData, Archive, Simulatoren und Logs. 256 GB eignen sich für kontrollierte Arbeitsbestände; große Assets, mehrere Toolchains oder langfristige Caches erfordern die Prüfung der 2-TB-Konfiguration oder zusätzlicher Speicheroptionen.
Abnahmekriterium Die Spitzenlast enthält temporäre Build-Dateien und lässt ausreichend Platz für Bereinigung und Export.Wählen Sie für einmalige Fehleranalyse, Sprints, Continuous Integration oder Langzeitexperimente einen Tages-, Wochen-, Monats- oder Quartalszeitraum. Rechnen Sie Einrichtung, Prüfung und Datenexport ein – nicht nur die Kompilierzeit.
Abnahmekriterium Endzeit, Verlängerungsprüfung und verantwortliche Person für den Export stehen fest.Schauen Sie vor der Bestätigung nicht nur auf den Einstiegspreis. Prüfen Sie zuerst, ob die Ressourcen den maximalen Arbeitsbestand abdecken, danach den Netzwerkpfad und zuletzt jeden USD-Betrag samt Zusatzoptionen.
Geeignet für reguläre Xcode-Builds, automatisierte Tests und kleine bis mittlere Cache-Bestände.
Geeignet für große Projekte, parallele Tests, KI-Experimente und Aufgaben mit größerem dauerhaftem Arbeitsbestand.
Wählen Sie anhand von maximalem Arbeitsspeicherbedarf, Plattenbestand und Anzahl paralleler Aufgaben eine der beiden Konfigurationen.
Wählen Sie Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong oder die westlichen USA.
Wählen Sie Tag, Woche, Monat oder Quartal und decken Sie Abnahme und Datenexport mit ab.
Prüfen Sie Basismodell, Standort, Zeitraum und Zusatzoptionen. Bestätigen Sie die endgültige USD-Abrechnung und senden Sie die Bestellung ab.
Unterstützt werden ausschließlich USDT-TRC20 sowie Visa / Mastercard / Amex (über Stripe). Alle Bestellungen werden in USD abgerechnet. Maßgeblich ist das vom Backend zurückgemeldete verfügbare Gateway.
Führen Sie nach Erhalt der Verbindungsdaten zunächst nur Identitätsprüfung, Zugangsdatenwechsel und einen minimalen Verbindungstest durch. Bei abweichendem Host-Fingerprint die Verbindung stoppen und das Konsolen-Ticket prüfen; Warnungen nicht überspringen.
Lesen Sie Gerätekennung, Hostadresse, Port, Benutzername und Host-Fingerprint aus den Bestelldetails der Konsole aus. Verwenden Sie dafür ausschließlich die aktuelle Bestellung.
Der beim ersten SSH-Verbindungsaufbau angezeigte Fingerprint muss mit den Bestelldetails übereinstimmen. Dokumentieren Sie das Ergebnis im internen Ticket.
Ändern Sie die temporären Zugangsdaten direkt nach der ersten Anmeldung. Speichern Sie sie über das vom Team freigegebene Schlüsselmanagement und verwenden Sie die alten Daten nicht mehr für den täglichen Zugriff.
Führen Sie zuerst SSH- sowie Datei-Lese-/Schreibtests aus und prüfen Sie anschließend bei Bedarf die Verbindung zur grafischen macOS-Oberfläche. Vorgehen und Portprüfung finden Sie in der Supportanleitung.
ssh -p <port> <user>@<host>
uname -m
sw_vers
df -h /
xcode-select -pHalten Sie Gerätekennung, Zeitpunkt und Zeitzone, Netzbetreiber, Fingerprint-Vergleich, Reproduktionsschritte, bereinigte Logs und bereits durchgeführte Prüfungen bereit. Übermitteln Sie keine Passwörter, privaten Wallet-Schlüssel oder vollständigen Kartennummern.
In der Konsole anmelden und Ticket erstellenÜbertragen Sie nicht alles auf einmal, um danach gemeinsam zu suchen. Definieren Sie für jeden Pfad Eingaben, Prüfpunkt und Rückfallaktion. Wechseln Sie erst nach erfolgreicher Prüfung zum nächsten Pfad.
Migrieren Sie nur für den Build benötigte Daten und vermeiden Sie lokale Caches, alte Archive und unbekannte Zustände.
Bauen Sie die Umgebung anhand einer Versionsliste neu auf, statt den gesamten lokalen Systemzustand zu kopieren. Installieren Sie zuerst notwendige Tools, danach Abhängigkeiten und Caches.
Binden Sie zunächst einen einzelnen Testzweig an den Runner an. Nach Prüfung von Isolation, Cache und Logübertragung stellen Sie Produktionsaufgaben auf den Cloud Mac um.
Erst bei identischen Daten-Hashes, reproduzierbarer Toolchain und stabilen CI-Builds den Branch- oder Parallelisierungsumfang erweitern. Während der Migration nicht gleichzeitig Abhängigkeiten, Signaturstrategie und Scheduling ändern.
Installation ist keine Abnahme. Nach jeder Konfigurationsstufe müssen Version, Pfad oder Berechtigung dokumentiert werden, damit die nächste Person dieselbe Checkliste reproduzieren kann.
Vorgegebene Projektversion installieren und aktives Entwicklerverzeichnis, SDK-Liste und Compiler-Version prüfen. Bei mehreren Versionen den Umschaltbefehl dokumentieren.
Commit-Identität, Hostprüfung und Zugangsdaten mit Minimalrechten konfigurieren. Danach Haupt-Repository, Submodule und große Dateien abrufen und Branch sowie Remote-Adresse prüfen.
Benötigte Materialien nach Teamprozess importieren und Zugriffskontrollen sowie Leserechte des Build-Prozesses prüfen. Sensible Inhalte gehören nicht in Quellcode, normale Logs oder gemeinsam genutzte Caches.
Abhängigkeiten anhand der Lockfiles wiederherstellen und wiederverwendbare Caches von neu zu erzeugendem Projektzustand trennen. Cache-Keys müssen Toolchain- und Dependency-Version enthalten.
Separate Pfade für Quellcode, DerivedData, Archive, Logs und exportierte Artefakte festlegen sowie Bereinigung und Export nach Aufgabenende definieren.
Die folgenden Ausgaben bilden die Basisumgebung für den ersten Build. Befehle je nach verwendetem Paketmanager anpassen; Schlüssel und vollständige Umgebungsvariablen nicht in Logs schreiben.
sw_vers
uname -m
xcodebuild -version
xcode-select -p
git --version
ruby --version
node --version
df -h /Ein erfolgreicher Compile allein reicht nicht. Die erste Abnahme muss Dependency-Restore, Tests, Archivierung, Signaturprüfung und Artefakt-Download abdecken. Dauer, Exit-Code und Logpfad werden mit demselben Commit verknüpft.
| Reihenfolge | Prüfung | Ausführung | Erfolgskriterium | Zu dokumentieren |
|---|---|---|---|---|
| 01 | Abhängigkeiten wiederherstellen | Alle Abhängigkeiten aus den Lockfiles auflösen und laden; private Quellen, Submodule und Cache-Treffer prüfen. | Keine Abweichung bei ungesperrten Versionen; Auflösung abgeschlossen; zentrale Paketversionen entsprechen der lokalen Basis. | Lockfile-Hash, Wiederherstellungsdauer, Cache-Key und Anzahl fehlgeschlagener Wiederholungen. |
| 02 | Automatisierte Tests | Vereinbarte Unit-, Integrations- und erforderliche Simulator-Tests ausführen. | Erwarteter Exit-Code; fehlgeschlagene Fälle eindeutig zugeordnet; Ergebnisdateien herunterladbar. | Testziel, Anzahl erfolgreicher und fehlgeschlagener Tests, Test-Logpfad. |
| 03 | Archivierung | Archive mit der Release-Konfiguration ausführen und Ziel, Scheme, SDK sowie Build-Einstellungen prüfen. | Vollständiges Archiv erzeugt; Build- und Commit-Nummer nachvollziehbar; Warnungen dokumentiert. | Archivdauer, Xcode-Version, Commit-ID und Archiv-Hash. |
| 04 | Signaturprüfung | Signaturidentität, Teamkennung, Provisioning-Profile, Entitlements und Paketkennung prüfen. | Signaturkette entspricht der Projekterwartung; sensible Materialien erscheinen weder in öffentlichen Logs noch in Artefaktverzeichnissen. | Prüfergebnis, Abweichungen, verantwortliche Person und Ausgabe des Prüfkommandos. |
| 05 | Artefakte herunterladen | Vereinbarte Artefakte exportieren und an den Abnahmeort herunterladen; Größe, Hash und Entpacken prüfen. | Artefakte vollständig herunterladbar, Hash identisch, Benennung und Aufbewahrung entsprechen der Teamregel. | Dateiname, Größe, Hash, Download-Dauer und Speicherort. |
Regenerierbare Caches leeren und ausführen, um vollständige Dependency-Wiederherstellung und Compilerlaufzeit zu messen. Freien Speicher vorher und nachher dokumentieren.
Bei unverändertem Code erneut ausführen, Cache-Key und korrekte Artefaktverwendung prüfen. Beide Builds müssen denselben Commit und dieselbe Toolchain verwenden.
Ein kontrolliertes Fehlerprotokoll aufbewahren und prüfen, dass Exit-Code, Kernfehler, Testergebnis und Artefaktstatus korrekt von CI erfasst werden.
Cloud Macs können 365 Tage im Jahr normal betrieben werden. Für langfristige Aufgaben benötigen Sie dennoch Prüfungen zu Speicher, Cache, Schlüsseln, Upgrades und Datenexport vor Bestellende. Verankern Sie diese in der täglichen Checkliste.
Überwachen Sie Quellcode, DerivedData, Archive, Caches und Logs getrennt. Schwellenwerte müssen freien Speicher und Wachstum berücksichtigen; Empfänger müssen Bereinigung oder Export ausführen können.
Empfohlene Angaben Gesamtkapazität, freier Speicher, tägliches Wachstum und maximale Archivgröße.Caches nach Projekt, Toolchain-Version und letzter Nutzung bereinigen. Lockfiles und Cache-Key-Protokoll behalten, damit erneutes Laden nachvollziehbar bleibt.
Empfohlene Angaben Cache-Pfad, Aufbewahrungsdauer, Bereinigungsbefehl, Ergebnis und freigegebener Speicher.Für Repository, Artefaktquelle und CI jeweils Zugangsdaten mit Minimalrechten einrichten und Ablauf sowie verantwortliche Person dokumentieren. Danach alte und neue Berechtigungen prüfen.
Empfohlene Angaben Zweck, Berechtigungsumfang, Ablaufdatum, rotierende Person und Prüfergebnis.Vor dem Upgrade Xcode, Command-Line-Tools, Signierung, Abhängigkeiten und Rückfallunterlagen an einer unkritischen Aufgabe prüfen. VMDebug legt keine geplanten Ausfallzeiten fest; Upgrades planen Sie nach Ihrem eigenen Aufgabenrhythmus.
Empfohlene Angaben Version vor dem Upgrade, Zielversion, Kompatibilität, Rückfallunterlagen und Zeitpunkt.Letzte funktionierende Aufgabendefinition, Toolchain-Liste und wichtige Artefakt-Hashes aufbewahren. Bei einem fehlgeschlagenen Change neue Aufgaben zunächst stoppen, geprüfte Konfiguration wiederherstellen und Fehler-Logs behalten.
Empfohlene Angaben Auslöser, Pausenmethode, Wiederherstellungsversion, Prüfkommando und verantwortliche Person.Code, Schlüssel, Archive, Logs und erforderliche Caches vor Bestellende exportieren und prüfen. Nach dem Download Hashes kontrollieren und nicht mehr benötigte sensible Inhalte vom Gerät entfernen.
Empfohlene Angaben Exportliste, Zielort, Hashprüfung, Abschlusszeit und prüfende Person.Bei jedem Build Exit-Code und wichtige Logs erfassen; wöchentlich Speicherwachstum und Cache prüfen; Zugangsdaten gemäß Teamsicherheitsregeln rotieren; Toolchain-Änderungen vorab auf Kompatibilität prüfen; vor Bestellende ausreichend Zeit für den Datenexport einplanen.
Wählen Sie VMDebug M4 oder VMDebug M4 Pro und einen Standort aus Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong oder den westlichen USA. Unterstützt werden ausschließlich USDT-TRC20 sowie Visa / Mastercard / Amex (über Stripe); alle Bestellungen werden in USD abgerechnet.