Dieser Leitfaden richtet sich an Entwickler und CI/CD-Engineers, die Oakmini erstmals nutzen. Wähle einen exklusiven Mac-mini-Physikknoten, verbinde dich per SSH oder VNC, stelle die Apple-Silicon-Toolchain wieder her, führe einen reproduzierbaren Build aus und binde den self-hosted Runner an deine bestehende Pipeline an.
$ uname -m
arm64
$ sw_vers -productVersion
macOS ready
$ system_profiler SPHardwareDataType
Chip: Apple M4
$ xcodebuild -version
Xcode toolchain detected
$ git --version
git ready
✓ environment baseline recordedLege Kompatibilität, Region, Laufzeit und Berechtigungen vorab fest. So vermeidest du, erst nach der Verbindung inkompatible Abhängigkeiten, zu wenig Speicher oder fehlende Repository-Berechtigungen zu entdecken. Speichere die Ergebnisse in der Projekt-Migrationsdokumentation.
Prüfe, ob die Abhängigkeit eine arm64 Version bereitstellt. Achte besonders auf Binärtools, Container-Images, native Erweiterungen und ältere Skripte. Kommt das Projekt aus einer Intel-Umgebung, liste zuerst alle Komponenten auf, die ersetzt oder neu kompiliert werden müssen.
file ./your-binaryZielarchitektur bestätigenWähle zwischen Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong und dem Westen der USA. Für interaktive VNC-Sitzungen empfiehlt sich die Nähe zu den wichtigsten Nutzern; für unbeaufsichtigte Builds zählen Quellcode, Artefaktspeicher und Teamstandorte.
ping / tracerouteVom tatsächlichen Büronetzwerk messenTage eignen sich für kurze Tests, Wochen für Migrationssprints und Monate oder Quartale für die laufende Entwicklung mit dauerhaftem Runner. Plane die gesamte Zeit für Vorbereitung, Build, Abnahme und Artefaktexport ein – nicht nur die Dauer einer einzelnen Aufgabe.
day / week / month / quarterBestelllaufzeiten nicht mischenSchätze Repository, Abhängigkeits-Cache, Simulator-Daten, Archive und exportierte Artefakte separat. Lass im Build-Verzeichnis Reserve, damit die Abhängigkeitsauflösung oder Archivierung nicht wegen vollem Speicher abbricht. Definiere für langfristige Aufgaben außerdem eine Cache-Bereinigungsstrategie.
df -hNach der Verbindung erneut prüfenFür Aufgaben auf der Kommandozeile benötigst du einen SSH-Client und Schlüssel; für die grafische macOS-Oberfläche einen VNC-Client. Prüfe, ob dein lokales Netzwerk die Verbindung zulässt, und dokumentiere den Einfluss von Firewall, Proxy oder VPN auf den Verbindungsweg.
ssh -VLokalen Client zuerst prüfenPrüfe die erforderlichen Berechtigungen für Repository-Lesen, Zugriff auf Abhängigkeitsquellen, CI-Runner-Registrierung, Build-Signaturmaterial und Artefakt-Upload. Verwende bevorzugt aufgabenspezifische Zugangsdaten und beschränke automatisierte Abläufe auf die erforderlichen Rechte.
read / build / uploadBerechtigungsumfang einzeln markierenOak Core und Oak Forge sind exklusive physische Mac-mini-Knoten, keine virtuellen Maschinen. Entscheide anhand von Spitzen-Speicherbedarf, parallelen Builds, Größe des Arbeitssatzes und Artefaktvolumen – nicht anhand vager Leistungsfaktoren.
Geeignet für das Debugging einzelner Projekte, Abhängigkeitsprüfungen, Automatisierungsaufgaben mit geringer Parallelität und kurze Migrationsprüfungen. Bei großen Repositories, Simulatoren oder Archiven solltest du beim Kauf mehr Speicher wählen.
Geeignet für parallele Projekte, große Abhängigkeitsgraphen, speicherintensive Kompilierung, Apple-Silicon-KI-Inferenztests sowie Aufgaben mit umfangreichen Caches und Build-Artefakten.
| Bestellfeld | Auswahl | Auswahlkriterium | Bestätigung |
|---|---|---|---|
| Abrechnungszeitraum | Tag, Woche, Monat, Quartal | Deckt Vorbereitung, Ausführung, Abnahme und Artefaktexport ab | Anfang und Ende der Bestellung entsprechen dem Plan |
| Knoten | Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong, Westen der USA | Tatsächlicher Netzwerkpfad zwischen Nutzern, Quellcode und Artefaktziel | Regionsname stimmt mit der Baseline überein |
| Speichererweiterung | +1TB SSD oder +2TB SSD | Gesamtvolumen von Repository, Cache, Arbeitsverzeichnis, Archiv und Exportartefakten | Reserve für Bereinigung und temporäre Dateien |
| Parallelschaltungsoption | Thunderbolt-5-Parallelschaltung (pro Gerät) | Nur für geplante Workflows mit mehreren Knoten auswählen | Anzahl und Topologie pro Gerät prüfen |
Lies Hoststatus, Adresse, Port und Zugangsdatenhinweise direkt aus dem Portal. Rate keine Parameter aus alten Bestellungen oder lokalen Verlaufsdaten. Für Aufgaben in der Shell verwendest du SSH, für die grafische Oberfläche VNC.
ssh -p <PORT> <USER>@<HOST>
hostname
sw_vers
uname -m
system_profiler SPHardwareDataType
df -h
systemsetup -gettimezone
dateSpeichere die Ausgabe in der Migrationsdokumentation. Sie sollte mindestens Hostname, macOS-Version,arm64 Architektur, Chipmodell, Speicherkapazität, Zeitzone und aktuelle Uhrzeit bestätigen.
Der Host muss als verbindungsbereit angezeigt werden. Ändert sich der Status noch, warte auf die Portalaktualisierung und wiederhole Zugangsdaten nicht fortlaufend.
Prüfe Hostadresse, Port, Benutzername und Verbindungsart einzeln. Schlüsseldateien dürfen nur auf kontrollierten Geräten gespeichert werden.
Notiere den Fingerabdruck bei der ersten SSH-Verbindung. Ändert er sich später unerwartet, brich die Verbindung ab und kläre dies über ein Konsolen-Ticket.
Verbinde dich per VNC zunächst mit einer für dein Netzwerk geeigneten Auflösung und Bildqualität. Prüfe anschließend Tastaturbelegung, Zwischenablage und Ruhezustand.
Erstelle zuerst eine überprüfbare Basisumgebung und installiere erst danach die Projektabhängigkeiten. Kopiere nicht einfach das gesamte Benutzerverzeichnis des alten Rechners. Migriere bevorzugt Listen, Konfigurationen und Lockfiles, um Architekturabweichungen und unbrauchbare Caches zu vermeiden.
Stelle die Softwareliste wieder her und führe die Diagnose aus. Übliche Apple-Silicon-Pfade müssen mit den fest codierten Skriptpfaden übereinstimmen oder entsprechend ersetzt werden.
brew bundle check && brew doctorRichte Commit-Identität, Zeilenumbruchregeln und die Methode zum Auslesen von Zugangsdaten ein. Klone zunächst ein schreibgeschütztes Test-Repository, um Netzwerk und Berechtigungen zu prüfen, bevor du das Produktionsprojekt bearbeitest.
git config --list --show-originStelle Ruby-, Node.js-, Python- und andere Laufzeitversionen anhand der Lockfiles wieder her. Dokumentiere Versionsmanager, globale Tools und projektbezogene Versionen; verlasse dich nicht auf die Angabe „aktuelle Version“.
ruby -v; node -v; python3 --versionPrüfe das aktuell ausgewählte Entwicklerverzeichnis, die Xcode-Version, das SDK und die Kommandozeilentools. Benötigen mehrere Projekte unterschiedliche Versionen, dokumentiere den Wechsel explizit in der Pipeline.
xcode-select -p; xcodebuild -versionStelle die Abhängigkeiten mit dem Lockfile des Repositorys wieder her und bewahre das vollständige Auflösungsprotokoll auf. Muss eine native Erweiterung kompiliert werden, prüfe, dass die Zielarchitektur arm64ist.
file ./path/to/native-extensiondate
hostname
sw_vers
uname -m
xcode-select -p
xcodebuild -version
git --version
brew --version
brew list --versions
ruby -v
node -v
python3 --version
df -hBeim ersten Build geht es nicht um die kürzeste Laufzeit, sondern um die reproduzierbare Prüfung von Abhängigkeitsauflösung, Signaturberechtigungen, Ausgabeverzeichnissen und Logs. Teste zunächst mit einem festen Commit und erweitere danach auf das vollständige Projekt.
Hole den angegebenen Commit oder Tag ab und prüfe Submodule, private Abhängigkeiten und große Dateien. Dokumentiere den Commit-Hash, damit sich die Eingaben während des Tests nicht ändern.
git rev-parse HEAD
Stelle die Abhängigkeiten über das Lockfile wieder her und schreibe Standard- sowie Fehlerausgabe in ein Log. Bei Architekturproblemen zunächst die konkrete Binärdatei ermitteln, statt die gesamte Umgebung wiederholt zu löschen.
command 2>&1 | tee dependency.log
Prüfe, ob der Build-Prozess auf benötigtes Signaturmaterial und Konfigurationsdateien zugreifen kann. Automatisierte Konten erhalten nur die für Projekt und Build-Schritte erforderlichen Rechte.
security find-identity -v -p codesigning
Lege DerivedData, Archive, Testergebnisse und exportierte Artefakte in klar definierten Verzeichnissen ab. Vermeide unkontrollierte temporäre Pfade, die von anderen Aufgaben gemeinsam genutzt werden.
mkdir -p build logs artifacts
Logs müssen mindestens Commit, Xcode-Version, SDK, Befehl, Startzeit, Endzeit und Exit-Code enthalten. Sensible Felder vor dem Upload anonymisieren.
echo "$?" > logs/exit-code.txt
Führe den Build mit identischem Commit und identischer Konfiguration erneut aus. So stellst du sicher, dass Abhängigkeiten, Pfade und Berechtigungen nicht von temporären Aktionen der ersten Sitzung abhängen. Beide Ergebnisse müssen nachvollziehbar und vergleichbar sein.
./scripts/verify-build.sh
xcodebuild \
-project Example.xcodeproj \
-scheme Example \
-configuration Release \
-derivedDataPath ./build/DerivedData \
build 2>&1 | tee ./logs/first-build.logDer Befehl endet mit Exit-Code 0; das Log verweist auf festen Commit und feste Toolchain-Versionen; das Ausgabeverzeichnis enthält die erwarteten Artefakte; eine erneute Ausführung benötigt keine undokumentierten manuellen Schritte.
Die drei Pfade können parallel vorbereitet werden, müssen aber über eine gemeinsame Baseline zusammenlaufen: fester Repository-Stand, dokumentierte Toolchain-Versionen, definierte Runner-Tags und anschließend eine reproduzierbare Prüfaufgabe.
Migriere nur nachvollziehbare Daten und keine historischen Zustände ohne klare Herkunft.
Tools aus der Liste wiederherstellen und das Ergebnis anhand der Versionsausgabe prüfen.
Sorge dafür, dass die Planungsregeln eindeutig auf diesen exklusiven physischen Knoten verweisen.
Eine lauffähige Umgebung ist nicht automatisch für den dauerhaften Einsatz geeignet. Nach dem ersten Build solltest du sofort anfängliche Zugangsdaten, Schlüsselablage, Repository-Umfang und sensible Informationen in Skripten prüfen.
Vor dem Commit nach typischen sensiblen Feldern suchen und Shell-Verlauf, Umgebungsdateien, CI-Konfiguration sowie Logs prüfen. Werden Zugangsdaten im Klartext gefunden, zuerst widerrufen und ersetzen, anschließend die Dateihistorie bereinigen.
Berechtigungen privater Schlüssel einschränken, nicht mehr verwendete öffentliche Schlüssel löschen und für automatisierte Verbindungen eindeutig benannte Schlüssel mit dokumentiertem Zweck konfigurieren.
chmod 600 ~/.ssh/private_key
Zeit, Befehle, Versionen, Exit-Codes und Fehler-Stacks aufbewahren; Zugriffstokens, private Schlüssel, originales Signaturmaterial und andere direkt zur Autorisierung nutzbare Informationen entfernen.
Die Abnahme muss auf reproduzierbaren Ergebnissen beruhen, nicht darauf, dass „es gerade funktioniert“. Trenne die Sitzung, verbinde dich erneut und führe die wichtigsten Befehle aus einer sauberen Shell erneut aus.
SSH und VNC aktiv trennen und mit den gespeicherten korrekten Parametern erneut verbinden. Host-Fingerabdruck, Benutzername, Port und grafische Sitzung müssen der Dokumentation entsprechen.
Abhängigkeiten aus dem Lockfile wiederherstellen; Exit-Code 0; Architektur nativer Komponenten korrekt; Installationslog gespeichert und frei von sensiblen Daten.
Build mit festem Commit und festen Toolchain-Versionen abschließen. Ausgabeverzeichnis eindeutig festlegen; die zweite Ausführung darf keine undokumentierten manuellen Schritte benötigen.
Archive, Testergebnisse und andere Zielartefakte müssen aus dem angegebenen Verzeichnis exportierbar sein. Dateinamen, Version und Prüfmethode müssen der Teamvereinbarung entsprechen.
Der self-hosted Runner ist online, seine Tags passen zur Zielaufgabe und er nimmt keine Jobs nicht autorisierter Projekte an.
Umgebungs-Baseline, Abhängigkeits- und Build-Logs, Exit-Code sowie Artefaktpfade sind archiviert; sensible Felder wurden anonymisiert.
Hoststatus, Bestellinformationen und Verwaltungseinstieg lassen sich im Portal prüfen. Alle Knoten laufen 365 Tage im Jahr durchgehend.
Öffne das Portal, prüfe die verfügbaren Knoten und wähle Oak Core oder Oak Forge, den Abrechnungszeitraum sowie die Speicheroptionen. Schließe anschließend Verbindung, Toolchain-Wiederherstellung und Abnahme anhand dieser Seite ab.