Das Team in Asien-Pazifik committet den Code, das Team in Nordamerika übernimmt den Build. Die Build-Umgebung bleibt im Rechenzentrum und ist nicht an den Feierabend einer einzelnen Person gebunden.
Ein kompletter Rechner exklusiv für Sie – keine virtuelle Maschine. Zwei Apple-M4-Konfigurationen, fünf Standorte, 365 Tage im Jahr verfügbar.
Ab $19.2 pro Tag. Stromversorgung, Netzwerk und Kühlung übernimmt das Rechenzentrum. Ihr Team konfiguriert Pipelines, Build-Warteschlangen und Freigaberechte.
Verlagern Sie den Xcode-Build-Rechner vom Büro ins Rechenzentrum. Jeder Push löst einen Auftrag aus – ohne darauf angewiesen zu sein, dass jemand den Rechner eingeschaltet und ans Stromnetz angeschlossen lässt.
Registrieren Sie auf dem Rechner einen selbst gehosteten macOS-Runner und konfigurieren Sie Branch-Trigger, Testziele und Artefaktpfade passend zum Repository. Prüfen Sie beim ersten Lauf, ob der Build über die Kommandozeile funktioniert. Erst danach richten Sie automatische Trigger ein, damit sich Umgebungs- und CI-Konfigurationsprobleme getrennt untersuchen lassen.
Für sequenzielle Builds einer einzelnen App eignet sich der Push M4 S als Einstieg: M4 / 16 GB / 256 GB SSD. Behalten Sie Abhängigkeiten und DerivedData im Cache, damit nachfolgende Aufträge dieselben Verzeichnisse nutzen können. Lassen Sie nicht mehrere Aufträge gleichzeitig in dieselben Build-Ausgaben schreiben.
Der Dauerbetrieb des Rechners macht Sie unabhängig von der Büroinfrastruktur und Stromausfällen vor Ort. Fehlgeschlagene Aufträge werden dadurch aber nicht automatisch wieder aufgenommen. Autostart des Runners, Wiederholungsversuche, Speicherbereinigung und Log-Benachrichtigungen müssen weiterhin in der Team-Pipeline eingerichtet werden.
Das folgende Beispiel verwendet App.xcworkspace und das Schema App im Projektverzeichnis. Ersetzen Sie die Namen vor der Ausführung durch die tatsächlichen Projektangaben.
xcodebuild -version
xcodebuild \
-workspace App.xcworkspace \
-scheme App \
-configuration Release \
-destination 'generic/platform=iOS' \
-derivedDataPath build/DerivedData \
-archivePath build/App.xcarchive \
archiveDie Signierung muss vorab eingerichtet sein. Dieser Befehl erstellt ein Archive, exportiert oder lädt es jedoch nicht hoch.
Das Team in Asien-Pazifik arbeitet tagsüber; ein Standort an der US-Ostküste kann Builds und Releases während des nordamerikanischen Arbeitstags übernehmen. Wählen Sie den Standort nach dem hauptsächlichen Einsatzort. Build-Aufträge werden über eine Warteschlange übergeben.
Dokumentieren Sie Branch, Commit, Schema, Xcode-Version und Build-Parameter. Die nächste Person arbeitet mit demselben Commit weiter, statt aus dem Chatverlauf zu erraten, welche Version zuletzt gebaut wurde.
Übergabedaten: Commit-Hash + Auftragsnummer.
Exklusive Nutzung bedeutet nicht unbegrenzte Parallelität. Richten Sie für den Mac eine Warteschlange oder Sperre ein und führen Sie Signierung und Export nacheinander aus. Verwenden Sie für unterschiedliche Projekte separate Arbeitsverzeichnisse und Cache-Schlüssel.
Übergabedaten: Warteschlangenstatus + Log-Pfad.
Prüfen Sie zunächst Testergebnisse, Archive und Export-Logs, bevor Sie die Release-Freigabe erteilen. Schlägt ein Auftrag fehl, sichern Sie den aktuellen Zustand und die Fehler-Logs, statt den Cache sofort zu löschen und den Auftrag erneut zu starten.
Übergabedaten: Artefaktpfad + Freigabestatus.
Verfügbare Standorte: Singapur, Tokio, Seoul, Hongkong und US-Ostküste. Für die VNC-Bedienung zählt vor allem der Standort der Person am Rechner; bei automatisierten Builds auch der Netzwerkpfad zu Repository und Abhängigkeitsquellen. Die Zeitzone erleichtert die Einsatzplanung, garantiert aber keine bestimmte Verbindungslatenz. Bei häufigen Arbeitsabläufen zwischen Kontinenten können Sie für beide Teams jeweils einen Rechner bereitstellen und die Runner-Tags vereinheitlichen.
Archive, Signierung und Upload für die Veröffentlichung im App Store erfolgen in einer festen Build-Umgebung. So reduzieren Sie Umzüge zwischen Umgebungen und müssen Signierressourcen nicht auf die Rechner aller Teammitglieder kopieren.
Legen Sie für den Release-Branch den Xcode-Pfad fest und dokumentieren Sie SDK sowie Lockfiles der Abhängigkeiten. Verlassen Sie sich nicht auf die zuletzt in der Benutzeroberfläche ausgewählte Version. Geben Sie in den Build-Logs die tatsächlich verwendete Toolchain aus.
Bewahren Sie Zertifikate und Provisioning-Profile zentral auf dem Release-Rechner auf und vergeben Sie für den Schlüsselbund nur die nötigen Rechte. Übergeben Sie Passwörter über geschützte CI-Variablen. Speichern Sie sie weder im Repository noch in der Befehlsausgabe oder in öffentlich zugänglichen Logs.
Bewahren Sie zunächst das xcarchive auf und exportieren Sie es anschließend mit einer vom Team geprüften ExportOptions-Konfiguration. Richten Sie Autorisierung und Freigabe für den Upload separat ein, damit sich Build-, Signier- und Upload-Fehler leichter unterscheiden lassen.
Verknüpfen Sie Versionsnummer, Commit-Hash, Build-Logs und Artefakte miteinander. Verwenden Sie Signierressourcen nur dort, wo sie benötigt werden, und bewahren Sie eine verschlüsselte Sicherung an einem vom Team kontrollierten sicheren Ort auf, um einen einzelnen Ausfallpunkt zu vermeiden.
Auch für die iOS-Builds mit Flutter und React Native ist die macOS-Toolchain erforderlich. Halten Sie native Abhängigkeiten, Pods und Xcode-Caches auf dem Rechner, damit Sie die Umgebung nicht jedes Mal neu einrichten müssen.
M4 / 16 GB / 256 GB SSD
Geeignet für die tägliche CI einer einzelnen App, eine einzelne Release-Warteschlange und erste Tests, ob sich ein plattformübergreifendes Projekt zuverlässig bauen lässt. Build, Simulator und andere Prozesse teilen sich den Arbeitsspeicher des Rechners. Führen Sie Aufträge daher zunächst nacheinander aus und beobachten Sie die Spitzenlast, bevor Sie weitere hinzufügen.
Behalten Sie die Lockfiles der Abhängigkeiten bei und verwenden Sie für unterschiedliche Branches eigene Cache-Schlüssel. Verschieben Sie ältere Artefakte in den Artefaktspeicher Ihres Teams, damit Archive nicht dauerhaft den lokalen Speicher belegen.
M4 / 24 GB / 512 GB SSD
Geeignet für Archive mit mehreren Targets, gemischte Flutter- und React-Native-Builds sowie Projekte, die mehr Abhängigkeiten und Toolchains gleichzeitig vorhalten müssen. Mit 24 GB steht parallelen Aufträgen mehr Arbeitsspeicher zur Verfügung; wie viele gleichzeitig laufen können, muss aber für jedes Projekt geprüft werden.
Erfassen Sie Build-Dauer, Speicherdruck und belegten Festplattenspeicher getrennt. Liegt der Engpass bei Downloads über große Entfernungen oder beim Warten auf die Signierung, löst mehr Arbeitsspeicher das Problem nicht direkt. Optimieren Sie zuerst Cache und Warteschlange.
Wenn mehrere Xcode-Versionen, Abhängigkeits-Caches und Archive immer mehr Speicher belegen, können Sie eine zusätzliche 1-TB- oder 2-TB-SSD erwägen. Mehr Speicherplatz bedeutet nicht mehr Arbeitsspeicher. Prüfen Sie zuerst, wodurch der Speicher belegt wird, bevor Sie erweitern.
Derselbe Cloud-Mac eignet sich auch für lokale Modellinferenz, Skripttests und kleinere Experimente. Prüfen Sie zuerst, ob das Modell in den gemeinsamen Arbeitsspeicher passt, und planen Sie die Aufgaben außerhalb der Release-Zeiten ein.
Der gemeinsame Arbeitsspeicher muss auch macOS, Inferenz-Framework, Kontext-Cache und weitere Prozesse aufnehmen. Die Dateigröße des Modells entspricht nicht dem benötigten Arbeitsspeicher zur Laufzeit. Testen Sie zuerst mit einer kurzen Eingabe und erhöhen Sie anschließend schrittweise Kontext und Batch-Größe.
Zu erfassen: Modellversion, Quantisierung, maximaler Speicherbedarf.
Verwenden Sie dieselbe Framework-Version, dieselben Testeingaben und Generierungsparameter, um Laufzeit und Ausgabe zu vergleichen. Entscheiden Sie zwischen 16 GB und 24 GB danach, ob die gewünschten Aufgaben stabil laufen. Gehen Sie nicht pauschal von einer bestimmten Modellgröße oder Geschwindigkeit aus.
Zu erfassen: Eingabelänge, Laufzeitparameter, Ausführungsdauer.
Inferenz und Xcode-Builds beanspruchen dieselben Rechen- und Speicherressourcen. Pausieren Sie die Experiment-Warteschlange während eines Releases. Verwenden Sie für Experiment-Skripte separate Verzeichnisse und Berechtigungen und greifen Sie nicht auf den Release-Schlüsselbund zu. Sichern Sie die Ergebnisse längerer Aufgaben regelmäßig.
Zu erfassen: Aufgabenpriorität, Abbruchkriterien, Ergebnispfad.
Geeignet für Tests, die macOS und Apple Silicon erfordern, nicht als Ersatz für groß angelegtes Training. Mieten Sie zunächst tageweise, testen Sie Ihre eigenen Workloads und entscheiden Sie anschließend über den längerfristigen Einsatz.
Die folgenden Beispiele veranschaulichen typische Aufgabenverteilungen zwischen zwei Rollen. Sie sind keine verifizierten Kundenbewertungen und enthalten keine gemessenen Verbindungswerte.
„Wir führen Fastlane auf einem fest zugewiesenen Rechner aus. Wer Bereitschaft hat, prüft denselben Build-Nachweis – niemand muss mehr darauf warten, dass jemand seinen Rechner einschaltet.“
„Ich teste zuerst die Verbindung zum Remote-Desktop über das Netzwerk eines Teammitglieds aus dem Testbereich und wähle danach den Standort. Automatisierte Tests laufen über die Warteschlange; für manuelle Prüfungen übernehme ich die Desktop-Sitzung.“
Für sequenzielle Builds einer einzelnen App reichen als Einstieg 16 GB; für mehrere Targets und gemischte Builds sollten Sie 24 GB prüfen. Wählen Sie den wichtigsten Standort für Ihr Team und bringen Sie dort zunächst Ihre erste Pipeline zum Laufen.
Exklusiver physischer Mac mini ab $19.2 pro Tag. Den tatsächlichen Verfügbarkeitsstatus sehen Sie in Echtzeit in der Konsole.