HexVM weist jeder Bestellung einen eigenen physischen Mac-mini-Knoten zu – keine virtuelle Maschine. Ihr Team kann bestehende Repositories, Skripte und Release-Regeln beibehalten und lediglich die Schritte, die macOS und Apple Silicon benötigen, in die Cloud verlagern.
Code-Repository
Commit als AuslöserDedizierter Knoten
Umgebung prüfenXcode
Build und TestsArtefakte
Archivieren und hochladenNicht jeder Schritt muss migriert werden. Wählen Sie einen Anwendungsfall, prüfen Sie den empfohlenen Ablauf, die benötigten Eingaben und die Abnahmekriterien – und entscheiden Sie anschließend über Knotenzahl und Ausführung.
Nach einem Commit plant die Repository-Plattform den selbst gehosteten Runner ein. Auf dem dedizierten Knoten werden Abhängigkeiten wiederhergestellt, Tests und Archivierung ausgeführt und Artefakte hochgeladen. Trigger, Parallelisierung und Schlüsselberechtigungen legt Ihr Team selbst fest.
iOS-CI/CD-Workflow ansehenAuf dem festen Knoten bleiben geprüfte Xcode-Versionen, Kommandozeilen-Tools und Dependency-Caches erhalten. Branch-Tasks verwenden eigene Arbeitsverzeichnisse; temporäre Daten werden nach dem Build entfernt, notwendige Artefakte bleiben bestehen.
macOS-Automatisierung ansehenFixieren Sie Modellversion, Laufzeitabhängigkeiten, Eingabebeispiele und Ergebnis-Baseline, um Tool-Kompatibilität, Batch-Skripte und die Wiederaufnahme laufender Tasks zu prüfen. Die Ressourcenlimits richten sich nach dem gewählten verfügbaren Modell.
Grenzen von KI-Experimenten ansehenIhr Team kontrolliert Zertifikate, Provisioning-Profile und den Zugriff auf den Schlüsselbund. Der Build-Knoten erstellt und validiert das Archiv; die abschließende Einreichung übernimmt ein autorisiertes Teammitglied.
Zertifikats- und Veröffentlichungsprozess ansehenVNC eignet sich für grafische Tools und UI-Prüfungen, SSH für Codesynchronisierung, Skriptausführung und fortlaufende Tasks. Prüfen Sie beim ersten Verbindungsaufbau die Knotendaten und ändern Sie die temporären Zugangsdaten sofort.
Leitfaden für Remote-Zugriff lesenEin dedizierter physischer Rechner eignet sich für Pipelines mit fester Xcode-Version, stabilem Cache-Verzeichnis und klar abgegrenzten Rechten. Der Knoten teilt keine Rechenressourcen mit anderen Bestellungen; Repository-Rechte, Signaturmaterial und Bereinigung der Tasks bleiben in der Verantwortung Ihres Teams.
Starten Sie Tasks über Branch, Tag oder Merge Request. Beschränken Sie zunächst auf Repository-Seite, welche Mitglieder den Release-Workflow auslösen dürfen, damit Test-Tasks keinen Zugriff auf Signaturen erhalten.
Abnahme: Trigger reproduzierbarVergeben Sie eindeutige Labels für den selbst gehosteten Runner, etwa für Chiparchitektur, Xcode-Hauptversion und Zweck. Die Parallelität pro Knoten sollte sich nach Speicherpeak und Schreibvolumen richten.
Abnahme: Tasks landen nur auf dem ZielknotenFixieren Sie Abhängigkeitsversionen und führen Sie Unit-Tests, UI-Tests oder statische Prüfungen aus. Bewahren Sie bei Fehlern Exit-Code, Testbericht und wichtige Logs auf – nicht nur die letzte Ausgabezeile.
Abnahme: Fehlerursache lokalisierbarEntsperren Sie den benötigten Schlüsselbund nur vorübergehend für Release-Tasks und schließen Sie den Zugriff danach sofort. Trennen Sie Zertifikate und Profile nach Projekt und Umgebung; speichern Sie sie nicht dauerhaft im Klartext im Build-Verzeichnis.
Abnahme: Rechte auf das Minimum begrenztLaden Sie Archiv, Testbericht und Symboldateien hoch und protokollieren Sie Commit-Hash, Build-Nummer und Toolchain-Version. Entfernen Sie anschließend sensible Projektdaten aus abgeleiteten Dateien.
Abnahme: Artefakte nachvollziehbarEin Test-Runner benötigt keinen Zugriff auf Release-Zertifikate. Nur Archivierungs-Tasks geschützter Branches laden Signaturmaterial. So vergrößert selbst ein Skriptfehler in einem normalen Task den Umfang offengelegter Zugangsdaten nicht.
Ein dauerhaft laufender Knoten kann geprüfte Toolchains und Download-Caches bereithalten; jeder Task sollte dennoch ein eigenes Arbeitsverzeichnis verwenden. Caches beschleunigen Builds, dürfen aber keine Voraussetzung für einen erfolgreichen Build sein.
Erstellen Sie Arbeitsverzeichnisse anhand der Task-ID und entfernen Sie temporäre Dateien nach dem Build. Lassen Sie niemals zwei parallele Branches dasselbe Abhängigkeitsverzeichnis oder denselben Ausgabepfad überschreiben.
Der Cache-Schlüssel sollte mindestens die Zusammenfassung des Lockfiles, die Toolchain-Hauptversion und die Architektur enthalten. Bei Problemen muss sich der Cache per Knopfdruck umgehen lassen, damit ein sauberer Build möglich ist.
Speichern Sie Testergebnisse, Unterlagen für die Beglaubigung, Installationspakete und Symboldateien getrennt. Der Artefaktname sollte Version, Build-Nummer und Commit-Kennung enthalten.
xcodebuild -version
xcode-select -p
swift --version
git rev-parse --short HEAD
xcodebuild test -scheme "Project" -destination "platform=macOS"Schreiben Sie die Versionsprüfung an den Anfang jedes Build-Logs. Vergleichen Sie bei Abweichungen zunächst Toolchain-Pfad, Projekt-Commit und Lockfile, bevor Sie den Cache bereinigen.
Ein Cloud-Mac eignet sich zum Reproduzieren von Experimentumgebungen, Prüfen der Toolchain-Kompatibilität und Ausführen wiederaufnehmbarer Batch-Tasks. Die Hardwarekapazität wird durch die zwei verfügbaren Konfigurationen begrenzt; Ergebnisse sollten nicht auf nicht aufgeführte Spezifikationen übertragen werden.
Speichern Sie Modellversion, Zusammenfassung der Beispiele, Zufalls-Seed und Laufzeitparameter. Verwenden Sie zum Vergleich dieselben Eingaben; ein einzelner Lauf ersetzt keine vollständige Validierung.
Fixieren Sie Runtime, Pakete und Version des Modellkonvertierungstools. Kopieren Sie die Umgebung vor einem Upgrade und führen Sie Regressionstests aus, um Änderungen bei Ausgabe und Ressourcenverbrauch zu prüfen.
Schreiben Sie bei fortlaufenden Tasks Fortschritt und Ergebnisse batchweise. Nach einem Prozessabbruch wird ab dem letzten bestätigten Batch fortgesetzt. Nicht persistenter Speicher darf nicht die einzige Fortschrittsquelle sein.
Protokollieren Sie Speicherpeak, Festplattenwachstum, Laufzeit und fehlgeschlagene Beispiele. Bei Erreichen der Modellgrenzen passen Sie zuerst Batchgröße oder Warteschlangenstrategie an.
Zuerst kopieren, dann prüfen, anschließend umstellen. Halten Sie einen lokalen Fallback bereit, bis der Cloud-Knoten Build, Rechte und Artefakte wiederholt erfolgreich abgenommen hat.
Phase eins
Kopieren Sie Projektdaten bevorzugt über Repository, Artefaktspeicher und verschlüsselte Übertragung. Lassen Sie Caches, temporäre Build-Verzeichnisse, alte Logs und nicht mehr verwendete Zugangsdaten außen vor.
Phase zwei
Dokumentieren Sie lokale Xcode-Version, Pfade der Kommandozeilen-Tools, Lockfiles des Paketmanagers, Herkunft der Umgebungsvariablen und Einstiegspunkte der Build-Skripte und bilden Sie sie in der Cloud nach.
Phase drei
Binden Sie zunächst nicht veröffentlichende Branches an. Prüfen Sie Labels, Timeouts, Logs und Bereinigungsregeln, bevor Sie geschützte Branches sowie Signierungs- und Archivierungs-Tasks freischalten.
Führen Sie mindestens einen sauberen Build, eine Fehlerwiederherstellung, eine Rechteprüfung und eine Artefakt-Rückverfolgung durch, bevor Sie den Cloud-Knoten als primäre Ausführungsumgebung festlegen.
HexVM stellt dedizierte physische Knoten und Remote-Zugriff bereit. Zertifikatsanträge, Provisioning-Profile, Schlüsselbundrechte, Release-Freigaben und die abschließende Einreichung verwaltet Ihr Team.
Zweck der Zertifikate festlegen, Exportpasswörter verwahren und zugriffsberechtigte Mitglieder begrenzen.
Benötigtes Material in einer kontrollierten Sitzung importieren; den Schlüsselbund nicht dauerhaft freigeben.
Zertifikatsname, Gültigkeit, autorisierte Mitglieder.
Profile nach App-ID und Release-Umgebung verwalten und ungültige Versionen entfernen.
Zuordnung vor dem Build prüfen und die Archivierung bei Fehlern stoppen.
App-ID, Teamdaten, Dateiversion.
Geschützte Branches und Release-Tasks freigeben sowie Build-Parameter kontrollieren.
Archivierung, Export und Integritätsprüfung ausführen und einen eindeutigen Exit-Code ausgeben.
Commit-Hash, Build-Nummer, Archivzusammenfassung.
Versionsdaten, Datenschutzangaben, Screenshots und Veröffentlichungsumfang prüfen.
Geprüfte Artefakte und Upload-Umgebung vorbereiten.
Einreichende Person, Artefaktversion, Ergebnis.
Nur während der Signierung entsperren und nach Abschluss sofort schließen. Verwenden Sie für verschiedene Projekte oder Umgebungen getrennte Zugriffsregeln, damit Test-Tasks keine Release-Rechte erben.
Prüfen Sie App-ID, Signaturidentität, Versionsnummer, Build-Nummer und Exportergebnis. Bei unerwarteten Werten den Upload stoppen und Fehler nicht manuell übergehen.
Runner-Registrierung widerrufen, Zertifikate und Profile entfernen, Repository-Zugangsdaten sowie sensible Felder aus Build-Verzeichnissen und Logs löschen und die Übertragung aller benötigten Artefakte bestätigen.
Für alle sechs Punkte sollten Verantwortliche und Abnahmeprotokolle feststehen. Was weiterhin nur mündlich vereinbart ist, kann bei Build-Fehlern, Personalwechseln oder der Freigabe eines Knotens zum Risiko werden.
Wählen Sie die Region nach Entwicklerstandort, Datenpfad des Repositories und Upload-Richtung der Artefakte. Verfügbar sind derzeit Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong, US-Ostküste und US-Westküste – insgesamt 6 Regionen.
Führen Sie zunächst einen vollständigen Build mit dem realen Projekt aus. Wählen Sie anschließend je nach Speicherpeak, Festplattenwachstum und Parallelität zwischen HexVM M4 und HexVM M4 Pro.
Trennen Sie Knotenverwaltung, tägliche Entwicklung, CI-Ausführung und Release-Rechte. Bei Team- oder Rollenwechseln müssen Schlüssel und Repository-Zugriffe sofort entzogen werden.
Verwenden Sie eingeschränkte Deployment-Zugangsdaten oder Runner-Berechtigungen und geben Sie nur die für den Task erforderlichen Repositories frei. Skripte dürfen Tokens, private Schlüssel oder vollständige Zugangsdaten nicht in Logs schreiben.
Protokollieren Sie Task-Warteschlange, Erfolgsquote, Fehlerursachen, Speicherbelegung und Laufzeit. Fortlaufende Tasks benötigen Wiederaufnahmepunkte, damit fehlgeschlagene Builds sicher erneut gestartet werden können.
Erfassen Sie pro Knoten effektive Build-Zeit, Wartezeit, Leerlauf und Cache-Effekt. Kurzfristige Tasks können tage- oder wochenweise geplant werden; für kontinuierliche Pipelines lassen sich Monats- und Quartalszeiträume vergleichen.
Verwenden Sie ein echtes Repository für sauberen und inkrementellen Build, Tests, Archivierung und Artefakt-Upload. Wenn Sie Unterstützung bei der Analyse benötigen, halten Sie Knoten-ID, Region, Zeitpunkt, Reproduktionsschritte und bereinigte Logs bereit.
Vergleichen Sie die zwei verfügbaren Modelle und Mietlaufzeiten. Nach Auswahl von Region und Zusatzoptionen können Sie direkt bestellen. Alle Preise werden in US-Dollar abgerechnet; die tatsächliche Verfügbarkeit wird in der Konsole in Echtzeit angezeigt.