Geeignet für leichte Builds einzelner Projekte, Unit-Tests und Archive mit geringer Parallelität. Abhängigkeits-Caches sollten regelmäßig bereinigt werden, damit das Arbeitsverzeichnis den lokalen Speicher nicht dauerhaft füllt.
ZoneMini M4 Core mieten
Integration in die Engineering-Pipeline
Cloud-Macs übernehmen Engineering-Aufgaben nach dem Commit
ZoneMini bietet dauerhaft laufende dedizierte physische Cloud-Mac-Hosts statt virtueller Maschinen. Übergeben Sie Code-Commits an feste Knoten und erhalten Sie Testberichte, Archive, Modellergebnisse oder Medienartefakte in Ihre bestehende Auslieferungskette zurück.
- Ressourcenmodell
- Eine Bestellung entspricht dem ausgewählten dedizierten physischen Knoten
- Katalogumfang
- 3 Konfigurationen, 5 verfügbare Knoten
- Zugänge
- SSH, grafische macOS-Oberfläche und CI Runner
BUILD-ROUTE
Ausführung auf festen Knoten
-
01Code-Commit Repository-Ereignis, Zeitplan oder manueller Trigger reiht den Auftrag einINPUT
-
02Build-Ausführung Abhängigkeiten wiederherstellen, Tests ausführen, signieren und archivierenRUN
-
03Artefaktübergabe IPA, Protokolle, Berichte, Modellmetriken oder Mediendateien zurückgebenOUTPUT
Vom Repository-Trigger bis zur IPA-Prüfung in sechs reproduzierbare Phasen
Ein stabiler iOS-Cloud-Build ist mehr als ein Archive-Befehl. Er benötigt eine feste Toolchain, kontrollierte Caches, begrenzte Signaturrechte und klare Artefaktprüfungen. Jede Phase sollte nachvollziehbare Protokolle hinterlassen, damit Fehler eindeutig Abhängigkeiten, Kompilierung, Signierung oder Export zugeordnet werden können.
-
01
Repository-Trigger empfangen
Starten Sie den Build durch einen Merge in den Hauptzweig, ein Release-Tag oder einen manuellen Auftrag. Schreiben Sie Branch, Commit-Hash, Versions- und Build-Nummer in den Auftragskontext, damit Artefakte dem Quellcode zugeordnet bleiben.
-
02
Gesperrte Abhängigkeiten wiederherstellen
Installieren Sie Swift Packages, CocoaPods oder JavaScript-Abhängigkeiten anhand der Lock-Dateien. Teilen Sie Caches nach Projekt, Toolversion und Lockfile-Hash auf, damit Branches keine falschen Abhängigkeiten wiederverwenden.
-
03
Signaturrechte freigeben
Entsperren Sie Zertifikate und Provisioning-Profile nur während des Builds und begrenzen Sie den Lesezugriff des Runners. Schließen Sie den temporären Zugriff nach Abschluss und schreiben Sie keine privaten Schlüssel, Tokens oder vollständigen Passwörter in Protokolle.
-
04
Tests ausführen und archivieren
Führen Sie zuerst statische Prüfungen und Unit-Tests aus, danach Xcode Archive. Bei einem Testfehler stoppen Sie die Signierung sofort und bewahren Testergebnisse, Compiler-Ausgabe und fehlgeschlagene Fälle auf.
-
05
IPA exportieren
Erzeugen Sie die IPA mit einer versionierten Exportkonfiguration und speichern Sie dSYM, Archivdatei und Exportprotokoll. Bewahren Sie nicht nur das fertige Installationspaket auf, sonst fehlen Grundlagen für Crash-Analyse und Versionsrückverfolgung.
-
06
Prüfungen vor dem Upload ausführen
Prüfen Sie Bundle ID, Versionsnummer, Build-Nummer, Signatur, Datenschutzmanifest und Paketänderungen. Übergeben Sie Artefakte erst nach erfolgreicher Prüfung an Upload oder Freigabe.
Konfiguration nach Auftragsumfang auswählen
Drei Katalogstufen für drei Build-Lasten
Bewerten Sie zuerst Spitzenarbeitsspeicher, Parallelität und Laufzeit pro Auftrag, bevor Sie ein Modell wählen. Beurteilen Sie nicht allein nach dem Projektnamen und verwechseln Sie wachsende Festplatten-Caches nicht mit Rechenbedarf.
Geeignet für die tägliche Entwicklung, Multi-Branch-Pipelines, native React-Native- oder Flutter-Builds sowie Teams mit umfangreicheren Abhängigkeits-Caches.
ZoneMini M4 Plus mietenGeeignet für parallele Builds mit hoher Last, große Modellinferenz, umfangreiche Medienaufgaben und lang laufende Batch-Verarbeitung. Aufgaben mit hohem Speicherbedarf sollten zuerst hier validiert werden.
ZoneMini M4 Pro mietenMehrere feste Runner als planbare Ressourcen statt als gemeinsam genutzte Workstations behandeln
Bei einer Build-Farm geht es nicht darum, jede Aufgabe beliebig auf jede Maschine zu verteilen, sondern Knoten mit stabilen Zuständigkeiten zu definieren. Labels, Warteschlangen, Cache-Grenzen, Protokollarchivierung und regionale Verteilung müssen gemeinsam geplant werden, damit Fehler lokalisierbar und Kapazitäten berechenbar bleiben.
RUNNER-ZUWEISUNG
Labels bestimmen das Ziel
ios-light
Commit-Prüfung und Unit-Tests
Kurze Aufgaben bevorzugen, Parallelität begrenzen, Warteschlange bei Fehlern sofort freigeben
ios-release
Signatur, Archivierung und Release-Kandidaten
Feste Toolchain und Berechtigungsgrenzen, vollständige Exportprotokolle aufbewahren
cross-platform
React Native und Flutter
JavaScript-, CocoaPods- und native Build-Caches trennen
high-memory
Modellinferenz und große parallele Aufgaben
An ZoneMini M4 Pro binden, Speicherhöchstwert und Ausgabeverzeichnis protokollieren
Warteschlangen nach Laufzeit und Berechtigungen trennen
Commit-Prüfungen, Release-Archive und speicherintensive Aufgaben sollten keine undifferenzierte Warteschlange gemeinsam nutzen. Geben Sie langen Aufgaben eigene Labels, damit kurze Tests nicht lange warten.
Caches nach Projekt und Version isolieren
Cache-Schlüssel sollten mindestens Projekt, Branch-Strategie, Toolversion und Lockfile-Hash enthalten. Bei Cache-Fehlern muss eine projektspezifische Bereinigung möglich sein, ohne den gesamten Knoten zu leeren.
Fehlerprotokolle zentral archivieren
Speichern Sie Commit-ID, Runner-Label, Xcode-Version, Abhängigkeitsübersicht, Fehlerphase und bereinigte Protokolle. Protokolle benötigen eine Aufbewahrungsfrist und dürfen keine Zugriffstokens enthalten.
Knoten nahe bei Repository und Team
Verfügbare Knoten befinden sich in Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong und an der US-Ostküste. Berücksichtigen Sie primär Repository-Standort, Teamzeitzone und Auslieferungsrichtung.
Bei React Native und Flutter liegt der Engpass meist in der nativen Ebene
JavaScript- oder Dart-Code kann in vielen Umgebungen entwickelt werden, doch iOS-Abhängigkeitsauflösung, Simulator-Tests, Signierung und Archivierung benötigen weiterhin macOS und Xcode. Ein fester Cloud-Mac verlagert diese Arbeit vom persönlichen Rechner in die Team-Pipeline.
React Native
JavaScript- und native Abhängigkeiten getrennt verwalten
- Abhängigkeiten wiederherstellen:Node.js-Pakete anhand der Lock-Datei installieren und anschließend im iOS-Verzeichnis die CocoaPods-Abhängigkeiten wiederherstellen.
- Cache-Grenzen:Cache-Schlüssel für Paketmanager, Pods und DerivedData getrennt festlegen und nicht das gesamte Arbeitsverzeichnis cachen.
- Testreihenfolge:Zuerst Typprüfung und JavaScript-Tests ausführen, danach native Unit-Tests oder Simulatorprüfungen starten.
- Signatur-Build:Der Release-Branch verwendet ein festes Scheme und erzeugt Archive, IPA, dSYM sowie Exportprotokolle.
- Multi-Branch-Strategie:Feature-Branches dienen nur der Validierung; Signaturrechte werden erst für Kandidaten-Branches freigegeben, damit nicht jeder Commit ein Release-Paket erzeugt.
Flutter
Dart- und Xcode-Phasen getrennt protokollieren
- Umgebung prüfen:Flutter-, Dart-, CocoaPods- und Xcode-Versionen festschreiben und zu Beginn jedes Auftrags eine Versionsübersicht ausgeben.
- Native Abhängigkeiten:iOS-Plugin-Abhängigkeiten wiederherstellen und prüfen, ob zusätzliche Systemberechtigungen oder eine bestimmte Mindestbereitstellungsversion erforderlich sind.
- Simulator-Tests:Komponententests und iOS-Simulator-Tests trennen und bei Fehlern Testberichte sowie Screenshots aufbewahren.
- Signaturarchiv:Mit einer kontrollierten Konfiguration ein iOS Archive erzeugen und anschließend Exportoptionen sowie Signaturergebnis prüfen.
- Branch-Isolation:Für stabile und experimentelle Branches unterschiedliche Arbeitsverzeichnisse verwenden, damit Build-Artefakte und Caches einander nicht überschreiben.
CHECK 01
Wird die Lock-Datei mit dem Commit aktualisiert?
Ändern sich Abhängigkeitserklärungen ohne Aktualisierung der Lock-Datei, sind lokale Erfolge und CI-Fehler nur schwer reproduzierbar.
CHECK 02
Benötigt das native Modul eine neue Toolchain?
Vor einem Plugin-Upgrade Xcode, Bereitstellungsziel und CocoaPods-Anforderungen prüfen und erst danach den festen Knoten aktualisieren.
CHECK 03
Kann der Cache sicher ungültig werden?
Jeder Cache muss nach dem Löschen neu aufgebaut werden können und darf nicht die einzige Quelle für Abhängigkeiten sein.
Hochspeicherknoten für kontinuierliche Modellexperimente einsetzen
Cloud-Macs eignen sich, Modellvorbereitung, Inferenz, Metrikerfassung und Ergebnisausgabe in einer festen Apple-Silicon-Umgebung zu bündeln. Sie ersetzen keine Trainingsplattform, eignen sich aber zur Validierung lokaler Inferenzpfade, für Batch-Experimente und zur Beobachtung der Ressourcenleistung unter macOS.
Empfohlene Konfiguration mit viel Arbeitsspeicher
ZoneMini M4 Pro
M4 Pro · 64GB · 2TB
01
Modell und Prüfsummen vorbereiten
Modellversion, Quelle, Dateiprüfsumme, Quantisierung und Skriptversion protokollieren. Große Dateien vor dem Kopieren ins Experimentverzeichnis auf Vollständigkeit prüfen.
02
Ausführungsumgebung isolieren
Für jedes Experiment eine eigene Umgebung anlegen und Python-Pakete sowie native Abhängigkeiten festschreiben. Vorübergehende Upgrades dürfen die validierte Basis nicht verändern.
03
Batch-Inferenz ausführen
Last schrittweise anhand von Batchgröße, Eingabelänge und Parallelität erhöhen. Spitzenarbeitsspeicher, Laufzeit, fehlerhafte Beispiele und Wiederholungen protokollieren.
04
Metriken und Ergebnisse exportieren
Parameter, Umgebungsübersicht, Ausgabedateien und bereinigte Protokolle gemeinsam exportieren. Nicht nur den Enddurchschnitt aufbewahren; auch Ausreißer müssen nachvollziehbar bleiben.
Langwierige Transkodierung festen Knoten überlassen und fertige Dateien ins Archivsystem übertragen
Audio- und Videoaufgaben beanspruchen meist Prozessor, Arbeitsspeicher und Speicher gleichzeitig. Ein sinnvoller Ablauf trennt Synchronisierung, temporäre Verarbeitung, Qualitätsprüfung und Rückübertragung, statt die Arbeitsdisk des Cloud-Macs als dauerhaftes Medienarchiv zu verwenden.
Medien synchronisieren und Prüfsummen kontrollieren
Quelldateien, Untertitel, Tonspuren und Verarbeitungsparameter anhand der Aufgabenliste synchronisieren. Nach der Übertragung Dateigröße oder Prüfsumme prüfen, bevor ein langer Auftrag startet.
- Eingabe
- Quellvideo, Tonspuren, Untertitel, Parametertabelle
- Protokollierung
- Dateiprüfsumme, Kodierungsvorgaben, Ausgabebenennung
Transkodieren und Proxy-Dateien erzeugen
Aufgaben nach Auflösung, Kodierungsformat oder Projektbatch aufteilen. Wenn Wellenformen, Proxy-Dateien oder Vorschaubilder benötigt werden, die Erzeugungsparameter im selben Auftrag speichern.
- Verarbeitung
- Batch-Transkodierung, Wellenformen, Proxy-Dateien, Vorschaubilder
- Isolation
- Eigenes temporäres Verzeichnis und eigene Fehlerliste je Batch
Automatisch prüfen, anschließend manuell stichprobenartig kontrollieren
Zuerst Dauer, Auflösung, Anzahl der Tonspuren und Vollständigkeit der Ausgabedateien prüfen, danach wichtige Passagen manuell kontrollieren. Nur den betroffenen Batch erneut ausführen.
- Automatisch
- Dauer, Abmessungen, Tonspuren, Dateivollständigkeit
- Manuell
- Bild, Ton, Untertitel und wichtige Passagen
Fertige Dateien übertragen und temporären Speicher bereinigen
Fertige Dateien, Verarbeitungsprotokolle und Fehlerlisten in den vorgesehenen Team-Speicher übertragen. Nach bestätigter Übertragung temporäre Dateien löschen, damit die lokale Festplatte nicht dauerhaft belegt wird.
- Artefakte
- Fertige Dateien, Protokolle, Liste fehlgeschlagener Aufgaben
- Abgrenzung
- Die Arbeitsdisk dient nicht als langfristiger Archivspeicher
Prüfungen vor der Einreichung als Pipeline-Gate umsetzen
Ein erfolgreiches Archiv bedeutet nicht automatisch, dass die Einreichung möglich ist. Versionsdaten, Signatur, Datenschutzmanifest, Archivprüfung, Screenshot-Assets und Release Notes müssen vor der Übergabe einzeln kontrolliert werden. ZoneMini stellt die Ausführungsumgebung bereit und ersetzt nicht die Prüfregeln der Vertriebsplattform.
RELEASE-GATE
Alle sechs Prüfungen bestehen, dann das Kandidatenpaket übergeben
Für jeden Kandidaten-Build Prüfresultate, Commit-Hash, Versionsnummer und Build-Nummer speichern. Bei Problemen zur entsprechenden Phase zurückkehren und vor der Einreichung keine nicht dokumentierten Konfigurationen ändern.
-
01
Versions- und Build-Nummer
Übereinstimmung mit Release-Branch, Änderungsprotokoll und Kandidatenpaket bestätigen; die Build-Nummer darf nicht doppelt vergeben sein.
-
02
Signatur und Provisioning-Profile
Prüfen, ob Bundle ID, Signaturidentität, Berechtigungen und Exportmethode dem Ziel entsprechen.
-
03
Datenschutzmanifest
Datenschutzerklärungen der App und ihrer Abhängigkeiten prüfen und bestätigen, dass neue SDKs berücksichtigt wurden.
-
04
Archivprüfung
Prüfausgaben speichern und fehlende Symbole, inkonsistente Berechtigungen oder nicht unterstützte Build-Einstellungen beheben.
-
05
Screenshots und Metadaten-Assets
Screenshots, Beschreibung und Aktualisierungsinformationen nach Zielgerät, Sprache und Version vorbereiten und Dateinamen prüfen.
-
06
Regression vor der Einreichung
Start, Anmeldung, Kernpfade, Netzwerkausfälle und Upgrade-Szenarien mit dem Kandidatenpaket prüfen.
Ausführungsumgebung und Prüfregeln getrennt verwalten
Cloud-Macs können Builds, Validierung und Artefaktaufbereitung kontinuierlich ausführen. App-Inhalte, Metadaten, Compliance-Anforderungen und die endgültige Prüfung richten sich jedoch nach den Regeln der jeweiligen Plattform. Teams sollten eigene Freigabe- und Rollback-Prozesse vorhalten.
Knoten nach Warteschlange, Berechtigungen und Zusammenarbeit kombinieren
Die Anzahl der Knoten sollte sich nicht allein an der Teamgröße orientieren. Prüfen Sie zunächst gleichzeitige Aufgaben, getrennte Signaturgrenzen, gemeinsam nutzbare Caches sowie die Verteilung von Mitgliedern und Repositories. Danach entscheiden Sie sich für einen oder mehrere Knoten.
1 dauerhaft verfügbarer Knoten
Einzelentwickler
Eine feste Umgebung für tägliche Entwicklung, Tests und Kandidatenarchive nutzen. Abhängigkeitsversionen, Signaturschritte und Bereinigungsskripte im Repository dokumentieren, um Unterschiede zwischen lokalem Rechner und Remote-Umgebung zu reduzieren.
- Für leichte Einzelprojekte mit ZoneMini M4 Core beginnen
- Für plattformübergreifende Projekte oder umfangreichere Caches ZoneMini M4 Plus bevorzugen
- Archive, Protokolle und aufzubewahrende Projektdaten regelmäßig exportieren
2 Aufgabentypen in der Warteschlange
CI-Team
Commit-Prüfung und Release-Archivierung mindestens trennen. Bei steigendem Volumen Knoten anhand von Labels ergänzen, damit Runner mit Signaturrechten nicht alle Standardtests übernehmen.
- Kurze Testwarteschlange bevorzugt bedienen, lange Archive separat einreihen
- Knotencaches nach Projekt isolieren und Fehlerprotokolle zentral archivieren
- Speicherintensive oder parallele Aufgaben an ZoneMini M4 Pro binden
5 Knoten zur Auswahl
Verteiltes Team
Wählen Sie zwischen Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong und der US-Ostküste den Standort nahe Repository, Hauptmitgliedern oder Auslieferungsweg. Verteilen Sie nicht einfach nach dem Durchschnitt der Teamstandorte.
- Bei häufigem Repository-Zugriff den Repository-Standort bevorzugen
- Bei viel Zusammenarbeit über die grafische Oberfläche auch die wichtigsten Nutzer berücksichtigen
- Auf allen Knoten dieselbe Toolchain-Liste und dasselbe Protokollformat verwenden
Zuerst bestätigen
Aufgabentypen und Spitzenparallelität
Auflisten, ob Build-, Test-, Inferenz- und Medienaufgaben gleichzeitig laufen.
Danach bestätigen
Arbeitsspeicher, Speicherplatz und Laufzeit
Die Konfiguration anhand der tatsächlichen Spitzenwerte aus den drei Katalogstufen wählen, nicht nach dem Projektnamen.
Zum Schluss bestätigen
Knoten, Laufzeit und Zahlungsmethode
Alle Bestellungen werden in USD abgerechnet. Unterstützt werden ausschließlich USDT-TRC20 sowie Visa / Mastercard / Amex (über Stripe).
Vor der Bestellung vorbereiten
Knoten und Konfiguration nach Auftragsumfang auswählen
Bereiten Sie Einsatzzweck, Anzahl paralleler Aufgaben, Zielknoten, Mietdauer und Speicherbedarf vor. Informationen zur Verbindung finden Sie im Leitfaden für Fernzugriff; für Konfigurationsempfehlungen können Sie das Team kontaktieren.