Vom lokalen Rechner in die Cloud
Die Migration in drei Schritten – mit Abnahmekriterien
Führen Sie zuerst einen einzelnen Build mit demselben Commit erfolgreich aus und richten Sie erst danach automatisierte Jobs ein. Die Zeitangaben dienen der Planung und sind keine Lieferzusage. Repository-Größe, Netzwerk, Downloads von Abhängigkeiten und die Vorbereitung der Signierung beeinflussen die tatsächliche Dauer.
01 / Daten
Quellcode synchronisieren, Build-Cache nicht übernehmen
Planen Sie 15–45 Minuten ein; große Repositories mit vielen Ressourcen können länger dauern.
Checken Sie möglichst einen festgelegten Commit aus dem Versionsverwaltungssystem aus. Noch nicht eingecheckte Dateien können Sie per SFTP oder rsync übertragen. Schließen Sie DerivedData, den Projektordner build und lokale Protokolle aus, damit keine veralteten Pfade oder nicht mehr gültigen Caches auf dem neuen Rechner landen.
Prüfen Sie die Dateiliste zuerst mit dry-run und starten Sie anschließend die eigentliche Synchronisierung. Ersetzen Sie USER und NODE_IP im Beispiel durch die Angaben aus der Instanzbereitstellung. Einen eigenen SSH-Port müssen Sie zusätzlich konfigurieren.
rsync -av --dry-run \
--exclude='DerivedData/' \
--exclude='build/' \
./ USER@NODE_IP:~/project/
git rev-parse HEAD
git status --short
Abnahmekriterien: Auf beiden Seiten derselbe Commit, alle benötigten Ressourcendateien vorhanden und keine vertraulichen Konfigurationen im Repository.
02 / Toolchain
Abhängigkeiten und Signierungsumgebung neu einrichten
Planen Sie 30–90 Minuten ein. Der erste Download kann länger dauern.
Notieren Sie die Versionen von Xcode, SDK, Homebrew und den Skriptabhängigkeiten auf Ihrem lokalen Rechner. Prüfen Sie zunächst mit brew --version ob Homebrew bereits installiert ist. Wenn das Projekt eine Brewfile enthält, stellen Sie die Abhängigkeiten anschließend anhand dieser Datei wieder her.
Übertragen Sie die für die Signierung benötigten p12-Dateien und Provisioning-Profile über eine verschlüsselte Verbindung. Importieren Sie das Zertifikat in einen eigenen Schlüsselbund und legen Sie das Profil im Verzeichnis des Build-Benutzers ab. Passwörter gehören weder ins Repository noch in Build-Protokolle.
brew --version
xcodebuild -version
xcodebuild -showsdks
security find-identity -v -p codesigning
Abnahmekriterien: Das SDK erfüllt die Projektanforderungen, die Signierungsidentität ist gültig und ein manuell gestartetes Archive wird vollständig erstellt.
03 / CI einrichten
Runner registrieren und danach automatische Auslöser aktivieren
Planen Sie 20–60 Minuten ein, ohne die Testdauer des Projekts.
Installieren Sie den selbst gehosteten GitHub-Actions-Runner oder den GitLab-Runner mit den Registrierungsbefehlen Ihrer Codeplattform. Das Registrierungstoken wird nur bei der Einrichtung benötigt. Speichern Sie kein Maschinenpasswort im Workflow.
Prüfen Sie die Labels self-hosted, macOS und ARM64 . Starten Sie zuerst manuell einen Build mit einem festgelegten Commit. Prüfen Sie Arbeitsverzeichnis, Pfad der Build-Artefakte und Signierungsberechtigungen, bevor Sie automatische Builds für Branches aktivieren.
uname -m
sw_vers -productVersion
xcode-select -p
git rev-parse HEAD
Abnahmekriterien: Der Runner ist online, der richtige Commit wird verwendet, das Archiv lässt sich abrufen und die Protokolle enthalten keine Zugangsdaten.
Wenn mehrere Jobs auf demselben physischen Knoten laufen, teilen sie sich weiterhin CPU, Unified Memory und SSD. Begrenzen Sie zuerst die Parallelität und erhöhen Sie sie schrittweise. So verwechseln Sie Konkurrenz um Ressourcen nicht mit einem Problem des Knotens.