Von der Bestellung bis zur ersten Archivierung
Dies ist keine Anleitung, die nur erklärt, wie Sie sich anmelden. Sie wählen zwischen zwei physischen Gerätekonfigurationen, bestimmen einen von vier Standorten im Asien-Pazifik-Raum und schließen anschließend die Absicherung der Zugangsdaten, die Wiederherstellung der Toolchain, die Prüfung von Code und Signaturen, die CI-Runner-Anbindung sowie die Abnahme des ersten Auftrags mit einer nachvollziehbaren Dokumentation ab.
Vorbereitung
Ziel der Vorbereitung ist, Gerätekonfiguration, Standort, Zugriff und Datenverantwortung eindeutig festzuhalten. Fehlt einer dieser Punkte, wird die spätere Umgebungswiederherstellung schnell zu improvisiertem Ausprobieren.
Klären Sie, ob das Repository SSH oder kurzlebige Zugriffstoken verwendet, und erfassen Sie private Abhängigkeiten, Submodule und Artefakt-Repositories. Kopieren Sie keine langfristig gültigen privaten Schlüssel. Erzeugen Sie für den Cloud-Mac ein eigenes Schlüsselpaar und vergeben Sie nur die für das Projekt erforderlichen Berechtigungen.
Ordnen Sie Zertifikate, Bereitstellungsprofile, Keychain-Zugriffsanforderungen und den Ablauf für den Archivexport. Migrieren Sie nur bereinigte Kopien, die für Tests erforderlich sind, dokumentieren Sie Importreihenfolge und Zugriffskontrolle und schreiben Sie niemals vollständige Zugangsdaten in Repository oder Build-Logs.
Wählen Sie zwischen Singapur, Japan (Tokio), Südkorea (Seoul) und Hongkong. Testen Sie die Verbindung zunächst aus dem tatsächlichen Büronetzwerk. Bei teamübergreifender Zusammenarbeit sollten Hauptnutzer und CI-Ursprungsnetzwerk jeweils separat prüfen.
Für kurzfristige Prüfungen eignen sich Tages- oder Wochenmieten, für stabile Projekte Monats- oder Quartalsmieten. Legen Sie unabhängig von der Laufzeit frühzeitig Sicherungsort, Exportverzeichnis und die für den Auszug verantwortliche Person fest.
Bestellung und Bereitstellung
In der Bestellung müssen nur Modell, Standort, Abrechnungszeitraum und Zusatzoptionen festgelegt werden. Maßgeblich ist der vom Control Panel in Echtzeit gemeldete Status; beide Modelle sind an allen vier angebotenen Standorten verfügbar.
NUMACS M4 Core Mit M4, 16 GB RAM und 256 GB SSD eignet sich dieses Modell für die Pflege eines einzelnen Projekts, tägliches Debugging und leichte Automatisierung. NUMACS M4 Plus Mit M4, 24 GB RAM und 512 GB SSD eignet sich dieses Modell besser für parallele Builds, größere Abhängigkeits-Caches und parallele Tests.
Verfügbar sind Singapur, Japan (Tokio), Südkorea (Seoul) und Hongkong. Bevorzugen Sie einen Standort mit stabilem Netzwerkpfad und geringer Round-Trip-Latenz für den Hauptnutzer; testen Sie vor der CI-Anbindung erneut aus dem Runner-Netzwerk.
Mietbar pro Tag, Woche, Monat oder Quartal. Die Laufzeit sollte Umgebungswiederherstellung, ersten Build, Fehlerbehebung und Artefaktexport abdecken – kalkulieren Sie nicht nur nach der Installationsdauer.
Große Asset-Bibliotheken, mehrere Xcode-Versionen, Simulator-Runtimes und langfristige Build-Caches belegen schnell Speicher. Bei zusätzlichem Bedarf können Sie während der Bestellung +1 TB SSD, +2 TB SSD oder Thunderbolt 5 für die Parallelisierung wählen.
Erste sichere Anmeldung
Importieren Sie Code und Zertifikate nicht sofort nach Erhalt der Gerätedaten. Führen Sie zuerst Zugangsdatenrotation, Prüfung der Zugriffspfade und Kontrolle der Administratorrechte durch und dokumentieren Sie den sauberen Ausgangszustand.
Richten Sie nach dem ersten Öffnen der grafischen macOS-Oberfläche sofort ein eigenes starkes Passwort ein. Verwenden Sie keine Passwörter aus Repository, E-Mail oder gemeinsam genutzten Teamsystemen und speichern Sie Zugangsdaten weder in Chats noch in Automatisierungsskripten.
Erzeugen Sie lokal ein ausschließlich für dieses Gerät bestimmtes Schlüsselpaar und hinterlegen Sie den öffentlichen Schlüssel in der Autorisierungsliste. Schalten Sie nach erfolgreicher Anmeldung per Schlüssel nicht benötigte Zugriffswege ab und dokumentieren Sie die verantwortliche Person für den Schlüsseltausch.
Prüfen Sie Auflösung, Tastaturbelegung, Zwischenablage-Richtlinien und das Verhalten bei Inaktivität. Der Remote-Desktop dient grafischen Tools, SSH Skripten und Diagnose; beide Wege müssen separat geprüft werden.
Führen Sie kontrolliert einen Administratorbefehl aus und bestätigen Sie die Berechtigungen für Softwareinstallation und Systemeinstellungen. Umgehen Sie Berechtigungsprobleme nicht durch das Deaktivieren von Sicherheitsmechanismen, sondern prüfen Sie zuerst Befehl, Dateibesitzer und Ausführungskontext.
Migrationspfad
Kopieren Sie nicht das gesamte lokale Verzeichnis auf einmal. Daten, Toolchain und CI haben unterschiedliche Fehlerursachen. Eine getrennte Migration ermöglicht schnelles Zurücksetzen und zeigt, ob das Problem bei Dateien, Versionen oder der Ausführungsumgebung liegt.
Migrieren Sie zuerst Repository, Konfigurationsliste und benötigte Assets und stellen Sie große Caches nur bei Bedarf wieder her. Prüfen Sie das Ergebnis per Prüfsumme oder Dateianzahl und kopieren Sie keine temporären Verzeichnisse, abgeleiteten Daten oder veralteten Archive mit.
Installieren Sie Xcode, Homebrew, Ruby, Node.js und Paketmanager anhand der Versionsliste neu. Lockfiles dienen als Wiederherstellungsgrundlage; Caches beschleunigen lediglich den Vorgang und ersetzen keine reproduzierbare Installation.
Registrieren Sie einen dedizierten Runner und konfigurieren Sie Arbeitsverzeichnis, Cache-Grenzen, Parallelitätslimit und Aufbewahrung von Fehler-Logs. Führen Sie zunächst Tests ohne Signatur aus und ergänzen Sie Archivierung und Export schrittweise.
Entwicklungsumgebung installieren
Das häufigste Problem eines neuen Geräts sind nicht fehlende Tools, sondern driftende Versionskombinationen. Stellen Sie zunächst eine stabil bauende Kombination wieder her und testen Sie Upgrades in einem separaten Branch.
| Ebene | Festzuschreibende Inhalte | Wiederherstellungsmethode | Abnahmenachweis |
|---|---|---|---|
| macOS | Vom Projekt geprüfte Hauptversion und Patch-Bereich des Systems | Aktuelles System zuerst dokumentieren, beim ersten Migrationslauf keine Hauptversion überspringen | sw_vers |
| Xcode | Xcode-Version, Pfad der Kommandozeilentools, SDK | Bestimmte Version installieren und Entwicklerverzeichnis eindeutig setzen | xcodebuild -version |
| Homebrew | Brewfile, Repository-Quelle, Versionen wichtiger Tools | Nach Liste neu installieren, altes Cache-Verzeichnis nicht direkt kopieren | brew bundle check |
| Ruby | Interpreter-Version, Bundler-Version, Gemfile.lock | Mit den Versionsdateien des Projekts wiederherstellen und danach Abhängigkeiten installieren | ruby -v |
| Node.js | Runtime-Version, Paketmanager-Version, Lockfile | Nach Versionsdatei installieren und im Modus für eingefrorene Lockfiles wiederherstellen | node -v |
| Projektabhängigkeiten | CocoaPods, Swift Package, JavaScript-Abhängigkeiten | Schrittweise wiederherstellen und Logs jedes fehlgeschlagenen Schritts separat aufbewahren | Abhängigkeitsauflösung ohne implizite Upgrades |
Speichern Sie nach dem ersten erfolgreichen Build die Versionsausgaben von System, Xcode, Ruby, Node.js, Paketmanagern und wichtigen Abhängigkeiten im internen Betriebsprotokoll. Vergleichen Sie bei der nächsten Migration oder Fehleranalyse zuerst die Baseline, bevor Sie die Umgebung ändern.
sw_vers\nxcodebuild -version\nruby -v\nnode -v\nbrew bundle checkCode- und Signaturanbindung
Codeabruf, Abhängigkeitswiederherstellung, Keychain-Zugriff und Archivexport müssen getrennt geprüft werden. So lässt sich auch bei einem Fehler im produktiven Projekt schnell feststellen, ob Repository, Abhängigkeiten oder Signaturberechtigungen betroffen sind.
Klonen Sie das Repository mit einem dedizierten SSH-Schlüssel und prüfen Sie Zugriffsrechte für Submodule und private Abhängigkeiten. Installieren Sie im Lockfile-Modus und aktualisieren Sie während der Migration nicht nebenbei alle Abhängigkeiten.
Importieren Sie nur für Tests benötigte bereinigte Signatur-Assets und beschränken Sie die Berechtigungen der Keychain-Datei. Wiederherstellungscodes, private Schlüssel oder vollständige Zahlungsdaten gehören niemals in Tickets, Repositorys oder gemeinsam genutzte Logs.
Führen Sie Build, Tests und Archivierung zunächst für ein minimales Testprojekt aus und wechseln Sie erst danach zum produktiven Projekt. Eine erfolgreiche Archivierung bedeutet nicht automatisch einen erfolgreichen Export; speichern Sie für den Export separat Logs und Artefakt-Prüfergebnis.
CI-Runner-Anbindung
Bei der Runner-Anbindung geht es nicht nur darum, „online“ zu sein. Arbeitsverzeichnisse müssen bereinigbar, Caches begrenzt und parallele Aufgaben voneinander isoliert sein; Fehler-Logs müssen erhalten bleiben.
Einen dedizierten Runner registrieren und nur eine nicht signierte Umgebungsprüfung ausführen.
Abhängigkeitswiederherstellung und Unit-Tests hinzufügen und bestätigen, dass der Lauf auch nach dem Leeren des Caches erfolgreich ist.
Archivierung hinzufügen und den Keychain-Zugriff im nicht interaktiven Sitzungsumfang prüfen.
Artefaktexport, Prüfsumme und Upload hinzufügen und eine vollständige Zeit-Baseline des Auftrags dokumentieren.
Abnahme des ersten Auftrags
Die Abnahme muss die vollständige Kette vom Codeabruf bis zum Artefaktexport abdecken und Dauer, Ressourcenreserven sowie Ergebnisse von Fehlerversuchen dokumentieren. Bei späteren Toolchain-Upgrades oder Projektwechseln dient diese Aufzeichnung als Vergleichsbasis.
Das Ziel-Commit in ein leeres Arbeitsverzeichnis klonen und private Abhängigkeiten, Submodule und Repository-Berechtigungen prüfen, ohne auf Altlasten aus vorherigen Verzeichnissen zu vertrauen.
Alle Abhängigkeiten per Lockfile wiederherstellen, Dauer bei kaltem und warmem Cache dokumentieren und implizite Versions-Upgrades ausschließen.
Unit-Tests und erforderliche automatisierte Tests ausführen und fehlgeschlagene Fälle, Wiederholungen und Log-Speicherort dokumentieren.
Build-Konfiguration, Signaturidentität und Archivpfad prüfen und bestätigen, dass nicht interaktive Aufgabe und grafische Oberfläche dasselbe Ergebnis liefern.
Lesbarkeit der Exportdateien prüfen, Dateigröße und Prüfsumme dokumentieren und erforderliche Artefakte an einen separaten Sicherungsort kopieren.
CPU-Spitze, Speicherdruck, freien Speicher vor und nach dem Build, Gesamtdauer und Cache-Größe als Grundlage für spätere Abweichungsanalysen speichern.
Laufender Betrieb
Die physischen NUMACS-Knoten laufen 365 Tage im Jahr kontinuierlich. Caches, Speicher, Sicherungen und Zugangsdaten müssen dennoch laufend gepflegt werden, damit der Projektstatus nicht nur auf einem Gerät vorhanden ist.
Arbeitsverzeichnis, DerivedData, Simulator-Runtimes, Paketmanager-Caches und ältere Archive prüfen. Nach Quelle bereinigen und keine Löschbefehle für das gesamte Laufwerk verwenden, deren Umfang nicht nachvollziehbar ist.
Nach jeder Anpassung an macOS, Xcode, Ruby, Node.js oder wichtigen Abhängigkeiten Tests und Archivierung erneut ausführen und Dauer sowie Fehlerunterschiede vor und nach der Änderung dokumentieren.
SSH-Schlüssel, Repository-Zugriffstoken und Gerätepasswörter regelmäßig wechseln. Beim Ausscheiden eines Mitglieds oder bei Berechtigungsänderungen den entsprechenden Zugriff sofort widerrufen und keine persönlichen Schlüssel teilen.
Exportieren Sie vor Ende der Miete Codeänderungen, Build-Artefakte, Umgebungsübersicht, CI-Konfiguration und erforderliche Logs. Prüfen Sie die exportierten Dateien per Prüfsumme und öffnen Sie sie testweise an einem anderen Ort.
Wählen Sie Modell, Standort, Laufzeit und Zusatzoptionen und verwalten Sie Bestellung und Gerät zentral im Control Panel. Unterstützt werden ausschließlich USDT-TRC20 sowie Visa / Mastercard / Amex (über Stripe); abgerechnet wird vollständig in US-Dollar (USD).