Diese Anleitung deckt die Vorbereitung, die Auswahl aus zwei exklusiven physischen Maschinen, vier Standorte, die erste SSH-Anmeldung und die Xcode-Build-Validierung ab. Arbeiten Sie die Schritte der Reihe nach durch.
Klären Sie vor der Bestellung, wer für Verbindung, Builds und Zugriffsverwaltung zuständig ist. So vermeiden Sie nach der Bereitstellung wiederholte Rückfragen. Für alle fünf Punkte sollte eine verantwortliche Person feststehen.
Stellen Sie sicher, dass die bestellende Person sich an der Konsole anmelden und Bestellungen, Abrechnung, Standorte und Gerätestatus einsehen kann. Die technische Leitung muss wissen, wer Tickets einreicht und Verlängerungen durchführt.
Bereiten Sie den vom Team freigegebenen Ed25519-Public-Key vor und übermitteln Sie ausschließlich den öffentlichen Schlüssel. Bewahren Sie den privaten Schlüssel auf einem kontrollierten Gerät oder in einem Schlüsselverwaltungssystem auf; senden Sie ihn nicht per E-Mail, Ticket oder Repository.
Ermitteln Sie anhand von Projekt, CI-Konfiguration und Abhängigkeiten die benötigte Xcode-Version und halten Sie zugleich die Mindestversion von macOS fest. Schreiben Sie nicht nur „neueste Version“, sondern eine überprüfbare Versionsnummer.
Stellen Sie sicher, dass der Standort mit einem eingeschränkten Deployment-Schlüssel oder einem kurzlebigen Token auf die benötigten Repositories zugreifen kann. Legen Sie zuerst den minimalen Berechtigungsumfang fest und entscheiden Sie dann, ob Artefakte geschrieben oder Statusmeldungen übertragen werden dürfen.
Wenn Sie eine grafische Oberfläche benötigen, bereiten Sie frühzeitig einen VNC- oder macOS-Bildschirmfreigabe-Client vor. Automatisierung, Diagnose und Dateioperationen sollten bevorzugt über SSH erfolgen, um die Abhängigkeit von grafischen Sitzungen zu reduzieren.
Beide Modelle sind physische Apple-Silicon-Knoten zur exklusiven Nutzung, keine virtuellen Maschinen. Singapur, Tokio, Seoul und Hongkong sind im Katalog verfügbar; maßgeblich ist die Echtzeitverfügbarkeit in der Konsole zum Zeitpunkt der Bestellung.
M4 · 16 GB RAM · 256 GB SSD
Geeignet für eine einzelne iOS-Build-Pipeline, tägliche macOS-Kompilierungen, Abhängigkeitsprüfungen und einen dauerhaft laufenden, schlanken selbst gehosteten Runner.
Auswahlkriterium: Messen Sie zunächst den Spitzenbedarf an Arbeitsspeicher und das Disk-Working-Set eines sauberen Builds und reservieren Sie zusätzlich Platz für Abhängigkeits-Cache, Logs und Artefakte.
M4 · 24 GB RAM · 512 GB SSD
Geeignet für größere Xcode-Workspaces, parallele Tests, Container-Workloads und Teams, die mehr Build-Cache und Artefakte vorhalten müssen.
Auswahlkriterium: Wenn der Runner gleichzeitig kompiliert, Simulator-Tests ausführt und Abhängigkeiten verarbeitet, prüfen Sie zuerst den Speicherhöchstwert und das Wachstum des Caches.
Wählen Sie einen Standort in der Nähe der wichtigsten Entwickler, der Codequelle oder des Automatisierungs-Entrypoints. Vergleichen Sie nicht nur einen einzelnen Ping, sondern beobachten Sie auch die Stabilität während der Arbeitszeit und die Erfahrung mit dem Remote-Desktop.
Mieten Sie tage-, wochen-, monats- oder quartalsweise. Für kurzfristige Tests wählen Sie den Zeitraum anhand der erwarteten Testdauer; bei stabilen Pipelines stimmen Sie die Laufzeit auf Veröffentlichungsrhythmus und Verlängerungsverantwortung ab.
Die Bestellung weist Basismodell, Laufzeit, Standort und Zusatzoptionen getrennt aus. Alle Preise und Abrechnungen erfolgen in US-Dollar (USD); prüfen Sie die Angaben vor der Zahlung erneut.
Prüfen Sie anhand der von der Konsole bereitgestellten Zahlungsdaten Netzwerk, Betrag und Bestellkennung. Vergewissern Sie sich vor der Überweisung, dass das TRC20-Netzwerk verwendet wird, und bewahren Sie den Transaktionsnachweis zur Abstimmung auf.
Kartenzahlungen werden über Stripe abgewickelt. Prüfen Sie nach der Rückkehr von der Zahlungsseite in der Konsole Bestellstatus und Rechnungsbetrag; die Browser-Rückkehrseite ist kein Nachweis für die Gerätebereitstellung.
Modellname, M4-Chip, Arbeitsspeicher und Basisspeicher müssen dem gewählten Tarif entsprechen.
Bestätigen Sie Tag, Woche, Monat oder Quartal und wählen Sie für einen Test nicht versehentlich eine langfristige Laufzeit.
Stellen Sie sicher, dass Singapur, Tokio, Seoul oder Hongkong mit Ihrem Verbindungsplan übereinstimmt.
Bestätigen Sie SSD-Erweiterung und Anzahl der Thunderbolt-5-Verbindungen und schließen Sie dann die Zahlung ab.
Welche Zahlungsgateways tatsächlich verfügbar sind, zeigt die Konsole. Eine abgeschlossene Zahlung bedeutet nicht, dass das Gerät bereits erreichbar ist; prüfen Sie weiterhin Bestellstatus und Lieferdaten.
Lesen Sie Adresse, Kontohinweise und Mietdauer erst aus, wenn der Gerätestatus „Verbindbar“ anzeigt. Verwenden Sie keine Chatverläufe, alten Screenshots oder Verbindungsdaten anderer Bestellungen.
Alle Felder müssen aus derselben Bestellung stammen. Stimmen Standort, Adresse oder Laufzeit nicht mit Ihren Erwartungen überein, brechen Sie die Verbindung ab und reichen Sie über die Konsole ein Ticket ein.
Prüfen Sie den Bestellstatus weiterhin in der Konsole. Für die Bereitstellungsdauer ist der in der Konsole bestätigte Zeitpunkt maßgeblich; versuchen Sie nicht wiederholt, eine noch nicht bereitgestellte Adresse zu verwenden.
Fügen Sie Ihrem Ticket Bestellkennung, erwarteten Standort, aktuellen Gerätestatus und Zeitpunkt der Feststellung bei. Fügen Sie keine Passwörter, privaten Schlüssel oder vollständigen Zahlungsdaten bei.
Bei der ersten SSH-Verbindung geht es nicht um die sofortige Installation von Abhängigkeiten, sondern darum, Zieladresse, Hostschlüssel, Benutzerkonto und Hardware der aktuellen Bestellung zuzuordnen.
$ export ZOOMMINI_HOST=assigned-host
$ ssh-keyscan -t ed25519 "$ZOOMMINI_HOST" | ssh-keygen -lf -
256 SHA256:7qV3mL9kR2nF4cX8 assigned-host (ED25519)
$ ssh build@"$ZOOMMINI_HOST"
Last login: remote session
build@zoommini-node ~ %
$ sw_vers
ProductName: macOS
ProductVersion: 15.2
BuildVersion: 24C101
$ system_profiler SPHardwareDataType
Hardware:
Model Name: Mac mini
Chip: Apple M4
Memory: 16 GB
$ uname -m
arm64Übernehmen Sie die zugewiesene Adresse in eine temporäre Umgebungsvariable oder in die SSH-Konfiguration, damit keine falsche Adresse in der Befehlshistorie landet. Wenn ein nicht standardmäßiger Port verwendet wird, dokumentieren Sie auch den Portparameter.
Vergleichen Sie den lokal ausgelesenen Ed25519-Fingerabdruck Zeichen für Zeichen mit dem Bereitstellungseintrag. Bei Abweichungen die Verbindung abbrechen und den geänderten Eintrag nicht direkt akzeptieren.
sw_vers bestätigt die macOS-Version,system_profiler bestätigt Chip und Arbeitsspeicher,uname -m sollte arm64zurückgeben.
Prüfen Sie zuerst die Xcode-Auswahl, führen Sie anschließend den Projekt-Build und zuletzt die automatisierten Tests aus. Bewahren Sie Exit-Code und wichtige Logs jedes Schritts auf, statt den Erfolg nur anhand der Oberfläche zu beurteilen.
$ xcodebuild -version
Xcode 16.2
Build version 16C5032aXcode-Version und Build-Version stimmen mit der Projektmatrix überein; der Befehl endet mit Exit-Code 0.
$ xcodebuild -scheme App build
Prepare packages
CompileSwiftSources normal arm64
Ld App normal arm64
** BUILD SUCCEEDED **Am Ende der Ausgabe steht BUILD SUCCEEDEDund es liegen keine Fehler bei Signatur, Abhängigkeiten oder Speicherplatz vor.
$ fastlane ios test
Resolving Swift Package Manager dependencies
Test Suite 'All tests' passed
Executed 48 tests, with 0 failures
fastlane.tools finished successfullyDie erwartete Testanzahl wird erreicht, die Fehlerzahl beträgt 0, fastlane endet erfolgreich und der Prozess liefert Exit-Code 0.
Führen Sie zunächst xcode-select -p aus, um das aktuelle Entwicklerverzeichnis anzuzeigen. Wechseln Sie anschließend gemäß der Team-Versionsmatrix; ändern Sie Projektdateien nicht direkt, um Versionsprobleme zu umgehen.
Prüfen Sie Repository-Berechtigungen, Paketmanagerpfad und Umfang des Netzwerkzugriffs. Speichern Sie die Fehlerprotokolle, bevor Sie den Cache leeren, damit die ursprünglichen Belege erhalten bleiben.
Prüfen Sie, wie Zertifikate, Bereitstellungsprofile und Runner-Berechtigungen geladen werden. Geheimnisse müssen über ein kontrolliertes Schlüsselverwaltungssystem injiziert werden und dürfen nicht in Skripten oder Build-Logs stehen.
Eine erfolgreiche Abnahme bestätigt nur die Funktionsfähigkeit der Toolchain. Vor der offiziellen CI/CD-Anbindung müssen Zugangsdaten aktualisiert, Public Keys verwaltet, Berechtigungen entzogen und die Rechte des Runners auf das erforderliche Minimum begrenzt werden.
Ersetzen Sie gemäß den Bereitstellungshinweisen alle anfänglichen Zugangsdaten, die geändert werden müssen. Verwenden Sie ein einzigartiges, kontrolliertes Passwort und nutzen Sie es nicht für lokalen Rechner, Repository oder andere Knoten.
Konfigurieren Sie für jede zugriffsberechtigte Person und jede Automatisierungsidentität einen eigenen Public Key. Lassen Sie nicht mehrere Personen denselben privaten Schlüssel verwenden; der Kommentar des Public Keys muss dem konkreten Zweck zuordenbar sein.
Löschen Sie während der Tests vorübergehend hinzugefügte Public Keys, Repository-Token, Administratorrechte und Freigaben für den Remote-Desktop. Zugriffe ausgeschiedener Mitglieder und deaktivierter Runner müssen sofort entzogen werden.
Der Runner darf nur benötigte Repositories lesen, vorgegebene Skripte ausführen und an den festgelegten Speicherort schreiben. Vergeben Sie nicht standardmäßig Systemadministratorrechte oder projektübergreifende Token.
Nehmen Sie den Knoten erst in die reguläre Planung auf, wenn alle fünf Punkte erfüllt sind: Bestellfelder stimmen überein, SSH-Fingerabdruck stimmt überein, Systemspezifikationen stimmen überein, Build und Tests enden mit Exit-Code 0 und temporäre Berechtigungen wurden entfernt.
Wählen Sie zunächst Modell, Standort und Laufzeit. Sobald das Gerät erreichbar ist, führen Sie in der angegebenen Reihenfolge Fingerabdruckprüfung, Systemprüfung, Build-Validierung und Berechtigungsabsicherung durch.