Hier geht es nicht um abstrakte Leistungsversprechen. Wir zerlegen Repository-Checkout, Dependency-Caching, parallele Tests, Archivierung, Verteilung und Laufzeitüberwachung in überprüfbare Schritte und zeigen, wie ein dedizierter physischer Mac mini in Ihre bestehende Engineering-Umgebung integriert wird. Jede Miete umfasst ein exklusives Gerät – keine virtuelle Maschine.
$ xcodebuild -workspace App.xcworkspace \
-scheme App -configuration Release archive
** ARCHIVE SUCCEEDED **Klären Sie zunächst, ob Ihre Aufgabe eine vollständige macOS-Umgebung, stabile lokale Ressourcen und einen dauerhaft online verfügbaren Node benötigt. Danach wählen Sie Modell und Mietdauer. Für jede Aufgabenart nennen wir Eingaben, Ablauf, Artefakte und Grenzen.
Geeignet für Projekte mit fester Xcode-Version, Dependency-Cache, Simulator-Tests und nachvollziehbaren Archivartefakten. Prüfen Sie insbesondere Toolchain-Versionen, Build-Parameter und Cache-Treffer.
Ausgabe: Archiv, Testergebnisse, Build-LogsTeilen Sie Unit-Tests, UI-Tests und verschiedene Ausführungsziele in unabhängige Aufgaben auf und weisen Sie sie per Label bestimmten Nodes zu. So bleiben Test- und Entwicklungsumgebungen voneinander getrennt.
Beobachten: Fehlertypen, Wiederholungen, LaufzeitVerbinden Sie mit fastlane Signaturprüfung, Archivierung, Upload und Veröffentlichungsprotokoll. Übergeben Sie sensible Werte über kontrollierte Umgebungsvariablen; Logs enthalten nur die für die Fehleranalyse erforderlichen, bereinigten Informationen.
Ausgabe: Upload-Log, Versionsinformationen, AuslieferungsprotokollGreifen Sie per Terminal oder grafischer Oberfläche auf eine vollständige macOS-Umgebung zu und verwalten Sie Repository, Build-Verzeichnis und temporäre Dateien getrennt. Geeignet für kurzfristige Projekte, standortübergreifende Zusammenarbeit und Kompatibilitätstests.
Prüfen: Verbindungsqualität, Sitzungswiederherstellung, DateisynchronisierungFür die lokale Validierung von Modellen mit hohem Bedarf an Unified Memory: Erfassen Sie Modellgröße, Speicherdruck, Swap, Laufzeit und Temperaturverlauf. Einzelne Läufe sind kein allgemeingültiger Benchmark.
Beobachten: Speicherdruck, Durchsatztrend, FestplattenbelegungTeilen Sie Build-, Test- und Verteilungsaufgaben nach Node-Fähigkeiten auf und verwenden Sie einheitliche Labels, Cache-Regeln und Artefaktnamen. Geeignet für Teams mit wachsender Build-Warteschlange und weiterhin erforderlicher Aufgabentrennung.
Verwalten: Aufgabenlabels, Warteschlangentiefe, Artefakt-RückgabeSuchen Sie nach Titel, Zusammenfassung oder geeignetem Modell und filtern Sie nach Build-Anleitungen, App Store, CI/CD oder Architekturvergleich. Die Modellhinweise in den Karten grenzen die Auswahl ein; die endgültige Konfiguration sollte anhand von Parallelität, Speicherspitzen und Artefaktgröße festgelegt werden.
Wählen Sie zunächst eine Cloud-Mac-Konfiguration und führen Sie anschließend SSH-Zugriff, Xcode-Versionsprüfung, Dependency-Caching, automatisierte Tests und Archivierung durch. Enthalten ist eine Checkliste zur Fehleranalyse für persönliche Projekte und CI-Aufgaben.
Prüfen Sie Zertifikate, Provisioning-Profile, Datenschutzerklärung, Versionsnummer, Archivierungsumgebung und Upload-Logs vor der Einreichung. So vermeiden Teams Nacharbeit durch abweichende Signaturen, Metadaten oder Build-Umgebungen.
Die vollständige Einrichtung von Runner-Registrierung, Label-Planung, dauerhaftem Dienst, Cache-Verzeichnissen, Parallelitätsstrategie und Schlüsselverwaltung – ergänzt um Hinweise, wie ein dedizierter physischer Rechner stabile, voneinander getrennte Builds ermöglicht.
Vergleichen Sie beide Ansätze nach Liefergeschwindigkeit, exklusiven Ressourcen, Leistungsstabilität, Upgrade-Flexibilität und Betriebsaufwand. So können iOS-, macOS- und Build-Automatisierungsteams nach ihrer Workload entscheiden.
Vergleichen Sie verwaltete Build-Dienste und selbst verwaltete Cloud-Macs hinsichtlich Umgebungskontrolle, Toolchain-Erweiterung, Aufgabentransparenz, langfristigem Betrieb und Teamzusammenarbeit. Eine Entscheidungstabelle unterstützt die Auswahl nach Projektphase.
Beginnen Sie mit der Runner-Installation, wählen Sie Executor und Registrierungseinstellungen und konfigurieren Sie Schlüsselbund, Build-Cache, Artefakt-Upload und Wiederholungen fehlgeschlagener Aufgaben. Abgeschlossen wird die Anleitung durch zentrale Betriebshinweise für dauerhaft laufende Pipelines auf Cloud-Macs.
Verkürzen Sie das Suchwort oder wechseln Sie zu „Alle Artikel“, um den vollständigen Inhalt zu sehen.
Ein reproduzierbarer Xcode-Build sollte nicht nur „erfolgreich“ oder „fehlgeschlagen“ hinterlassen. Die Pipeline muss Codeversion, Toolchain-Version, Dependency-Status, Testziele, Archivparameter und Artefaktpfad erfassen, damit sich nach einem Fehler schnell feststellen lässt, ob Code, Umgebung oder externe Abhängigkeiten die Ursache sind.
Verwenden Sie den Commit-Hash statt eines veränderlichen Branches als Build-Eingabe und synchronisieren Sie die Submodule. Bewahren Sie Repository-Status und Commit-ID im Log auf, damit die tatsächlich gebaute Codeversion nachvollziehbar bleibt.
Erzeugen Sie den Cache-Key aus Lockfile-Hash und Toolchain-Version. Auch bei einem Treffer im alten Cache muss die Dependency-Integrität geprüft werden; ein erfolgreicher Cache-Treffer bedeutet nicht automatisch, dass die Abhängigkeiten nutzbar sind.
Gruppieren Sie Unit-Tests, UI-Tests und verschiedene Simulatorziele. Die Parallelität sollte von Teststabilität, Speicherspitzen und Lesbarkeit der Logs bestimmt werden – nicht von einer möglichst hohen Aufgabenanzahl.
Speichern Sie nach der Archivierung Build-Logs, Testberichte, Artefakt-Prüfsummen und Laufzeiten. Die Verteilung akzeptiert nur validierte Archive; beim Upload wird nicht erneut gebaut.
$ git checkout "$COMMIT_SHA"
HEAD is now at 8f2c1d4 release candidate
$ xcodebuild -version
Xcode 16.x
Build version verified
$ xcodebuild test \
-workspace App.xcworkspace \
-scheme App \
-destination "$SIMULATOR_TARGET"
Test Suite 'All tests' passed
$ xcodebuild archive \
-workspace App.xcworkspace \
-scheme App \
-archivePath artifacts/App.xcarchive
** ARCHIVE SUCCEEDED **
$ shasum -a 256 artifacts/manifest.json
d4b8...c91a artifacts/manifest.jsonDie Runner-Anbindung ist nur der erste Schritt. Für einen stabilen Betrieb brauchen Sie klare Labels, Parallelitätsgrenzen, Wiederholungsbedingungen, Cache-Verantwortung und Regeln zur Artefakt-Rückgabe. Ein dedizierter physischer Node teilt seine Ressourcen nicht mit anderen Mietern; dennoch muss Ihr Team die Konkurrenz zwischen Aufgaben auf demselben Node steuern.
| Phase | Empfohlene Vorgehensweise | Zu erfassen | Fehlerbehandlung |
|---|---|---|---|
| Runner-Registrierung | Feste Labels nach Zweck vergeben und Build-, Test- und Verteilungsaufgaben unterscheiden | Node-Name, Runner-Version, Label-Sammlung | Bei ungültiger Registrierung neue Zugangsdaten erzeugen und offengelegte Informationen nicht wiederverwenden |
| Parallelitätssteuerung | Das Limit paralleler Aufgaben anhand von Speicherspitzen und Festplatten-Schreiblast festlegen | Warteschlangenlänge, Start- und Endzeit der Aufgaben | Bei anhaltend hoher Ressourcenlast Parallelität reduzieren und Aufgaben aufteilen |
| Wiederholung bei Fehlern | Nur klar erkennbare Netzwerk- oder externe Abhängigkeitsfehler automatisch wiederholen | Erster Fehler, Wiederholungsgrund, Endstatus | Code- und Signaturfehler direkt abbrechen, um keine Zeit durch Wiederholungen zu verlieren |
| Cache-Verwaltung | Cache-Key aus Projekt, Lockfile und Toolchain-Version zusammensetzen | Cache-Treffer, Größe, Erstellungsquelle | Bei Verunreinigung den betreffenden Key löschen, nicht den Cache des gesamten Projekts leeren |
| Artefakt-Rückgabe | Nach Commit und Pipeline-Nummer benennen und vor dem Upload eine Prüfsumme erzeugen | Pfad, Größe, Hash, Aufbewahrungsregeln | Bei fehlgeschlagener Rückgabe lokale Kopie behalten und den Upload separat wiederholen |
Labels sollten reale Fähigkeiten ausdrücken, etwa Build-Toolchain, Aufgabentyp und verfügbare Ressourcen. Vermischen Sie Team-, Projekt- und Umgebungsnamen nicht in einem unlesbaren langen Label.
Netzwerkprobleme können begrenzt wiederholt werden; Kompilierungsfehler sollten nicht automatisch erneut ausgeführt werden. Bewahren Sie bei jeder Wiederholung die Ursache des ersten Fehlers auf, damit ein späterer Erfolg keine Instabilität verdeckt.
Verwenden Sie für Archive, Testberichte und normale Logs unterschiedliche Aufbewahrungsregeln. Artefakte erhalten eine Prüfsumme, Logs werden bereinigt und temporäre Verzeichnisse nach Aufgabenende regelbasiert entfernt.
Eine automatische Verteilung umfasst meist die Prüfung von Signaturmaterial, Schlüsselbundberechtigungen, Archivexport, Upload und Rückmeldung des Veröffentlichungsstatus. Logs sollten Schritte, Ergebnisse und Fehlerkategorien enthalten; private Schlüssel, Zugriffstoken, Zertifikatspasswörter und vollständige Zugangsdaten müssen jedoch verborgen bleiben.
Prüfen Sie, ob die erforderlichen Zertifikate und Provisioning-Profile verfügbar sind, und kontrollieren Sie Ziel, Bundle-ID und Build-Konfiguration. Passwörter oder ursprüngliche Zugangsdaten dürfen nicht im Log erscheinen.
Validieren Sie Archivpfad, Versionsnummer, Build-Nummer und Exportergebnis. Der Upload verwendet das validierte Artefakt erneut und ändert die Build-Konfiguration nicht kurzfristig.
Speichern Sie bereinigten Upload-Status, Request-ID und Fehlerkategorie. Bei einem Fehler unterscheiden Sie zunächst zwischen Signatur-, Netzwerk-, Metadaten- und serverseitigen Verarbeitungsproblemen.
[10:14:02] Checking signing materials
[10:14:03] Certificate: ********A91C
[10:14:03] Profile: verified
[10:14:05] Building archive
[10:21:48] Archive completed
[10:21:49] Exporting application package
[10:23:17] Upload started
[10:25:41] Upload accepted
[10:25:42] Release metadata recorded
[10:25:42] Sensitive values redactedÜbermitteln Sie bei einer Supportanfrage nur Reproduktionsschritte, Zeitraum, Fehlerkategorie und bereinigte Ausschnitte. Senden Sie niemals private Schlüssel, Zugriffstoken, Zertifikatspasswörter oder vollständige Zugangsdaten.
Die Konfiguration MacRents M4 Pro verfügt über M4 Pro, 64 GB Arbeitsspeicher und 2 TB lokalen Speicher. Sie eignet sich für die lokale Validierung von Modellen mit hohem Bedarf an Unified Memory und für Experimente mit mehreren Aufgaben. Ob sie für ein konkretes Modell passt, hängt weiterhin von Modellgröße, Quantisierung, Kontextlänge, Batchgröße und Laufzeit-Framework ab.
Fixieren Sie Modelldatei, Quantisierung, Kontextlänge, Batchgröße und Framework-Version. Eine einzelne Laufzeit ohne dokumentierte Eingabebedingungen ist nicht für Vergleiche zwischen Aufgaben geeignet.
Erfassen Sie gleichzeitig Speicherdruck, Swap, CPU- und GPU-Auslastung, Festplatten-I/O und Temperaturverlauf. Sowohl Spitzenwerte als auch Dauerzustände müssen erhalten bleiben.
Die Validierung lokaler Modelle eignet sich zum Vergleich von Parametern und Abläufen. Vor dem Produktiveinsatz müssen Sie jedoch Parallelität, Fehlerwiederherstellung, Ladezeit des Modells und Stabilität im Dauerbetrieb testen.
Verwenden Sie für jedes Experiment eine eigene Aufgaben-ID und speichern Sie Startparameter, Laufzeit-Logs und Ressourcenmessungen. Legen Sie Modelldateien in separaten Verzeichnissen ab, damit Experimente keine gleichnamigen Dateien überschreiben.
$ vm_stat
$ memory_pressure
$ powermetrics --samplers cpu_power,gpu_power
$ df -h
$ ps -axo pid,%cpu,%mem,etime,commandDie Artikel zeigen Workflows; die Konfigurationsentscheidung muss bei der konkreten Aufgabe ansetzen. Wenn Sie die folgenden Informationen klären, lässt sich meist bestimmen, mit welchem Modell Sie beginnen sollten und ob für parallele Aufgaben zusätzliche Ressourcen eingeplant werden müssen.
Toolchain: Dokumentieren Sie Versionen von Xcode, Dependency-Management-Tools, Runnern und Automatisierungsskripten.
Parallelität: Unterscheiden Sie gleichzeitig laufende Build-, Test-, Verteilungs- und Experimentieraufgaben.
Ressourcenspitzen: Erfassen Sie Speicherdruck, Festplattenbelegung, Cache-Größe und Artefaktgröße.
Betriebsdauer: Klären Sie, ob es um eine kurzfristige Validierung, phasenweise Entwicklung oder eine dauerhaft online verfügbare Pipeline geht.
Fehlerpfad: Definieren Sie Wiederholungen, Log-Aufbewahrung, Artefakt-Rückgabe und Bedingungen für manuelle Eingriffe.
MacRents bietet drei Tarife mit dedizierten physischen Mac-mini-Nodes. Vergleichen Sie zunächst Chip, Arbeitsspeicher, Speicher und Mietdauer und wählen Sie anschließend Node und Zusatzoptionen im Bestellprozess. Alle Nodes laufen 365 Tage im Jahr regulär; die tatsächliche Verfügbarkeit wird in Echtzeit über die Konsole angezeigt.