Schritt 2 · Abhängigkeiten der Reihe nach migrieren
Lokaler Mac → Cloud-Mac.
Die Reihenfolge lautet: Daten, Toolchain, CI. Migrieren Sie zuerst ein Projekt, das sich unabhängig prüfen lässt. Kopieren Sie nicht gleich das gesamte Benutzerverzeichnis. Die Zeitangaben sind Richtwerte; Repository-Größe, Netzwerk und Downloads beeinflussen den tatsächlichen Ablauf.
01 / Daten
Code und Signierung zuerst
Klonen Sie das Repository mit Git und wechseln Sie zum selben Commit wie auf Ihrem lokalen Rechner. Verwenden Sie für private Repositories einen eingeschränkten Deploy-Schlüssel oder ein kurzlebiges Token. Schreiben Sie keine langfristigen Zugangsdaten in die Repository-URL.
git clone <Repository-Adresse>
git rev-parse HEAD
rsync -av --progress ./Assets/ \
admin@<Knotenadresse>:~/work/Assets/
Wenn Sie signieren müssen, exportieren Sie aus dem lokalen Schlüsselbund eine Datei mit privatem Schlüssel im Format .p12 und übertragen Sie sie mit einem separaten Passwort verschlüsselt. Importieren Sie die Datei anschließend in den Schlüsselbund des Knotens. Migrieren Sie das Bereitstellungsprofil separat und prüfen Sie Zertifikatslaufzeit, Team und Zielkonfiguration.
Synchronisieren Sie größere Ressourcen inkrementell mit rsync. Verwenden Sie beim ersten Lauf keine Löschoptionen. Prüfen Sie zuerst das Zielverzeichnis, damit keine neu erzeugten Artefakte auf dem Knoten versehentlich gelöscht werden.
02 / Toolchain
Versionen wiederherstellen, Caches nicht kopieren
Exportieren Sie lokal ein Brewfile und übertragen Sie es auf den Knoten, um die Umgebung wiederherzustellen. Lesen Sie die Paketliste vorher durch und entfernen Sie nicht benötigte Desktop-Apps sowie veraltete Abhängigkeiten, damit der erste Download kleiner ausfällt.
brew bundle dump --file=Brewfile
brew bundle --file=Brewfile
xcodes list
xcodes install <benötigte-Version>
Prüfen Sie, welche Versionen von Xcode, Ruby und CocoaPods das Projekt benötigt. Beachten Sie bei der Installation mit xcodes die Lizenzbedingungen und Downloadberechtigungen. Prüfen Sie nach der Installation mit xcodebuild -version welche Version tatsächlich ausgewählt ist.
Bei Projekten mit Gemfile führen Sie bevorzugt bundle exec pod installaus. SPM löst Abhängigkeiten anhand der projektspezifischen Lockdatei auf. Der erste Build dient zum Aufwärmen des Caches und sagt nichts über die Geschwindigkeit späterer Builds aus.
03 / CI-Integration
Erst manuell erfolgreich bauen, dann Runner registrieren
Führen Sie zuerst in einer interaktiven Sitzung einen Build mit Signierung durch. Registrieren Sie erst dann einen GitHub Actions self-hosted runner oder GitLab Runner, wenn sich über die Kommandozeile ein Archiv erstellen lässt. So müssen Sie Toolchain und CI-Konfiguration nicht gleichzeitig prüfen.
bundle exec fastlane match development --readonly
bundle exec fastlane gym
Signierungstyp und konkrete Lane für match richten sich nach der Projektkonfiguration. Verwenden Sie in CI eingeschränkte Zugangsdaten und speichern Sie Schlüssel in geschützten Variablen oder einem Schlüsselmanagement – niemals Passwörter direkt im Skript.
Weisen Sie dem temporären Runner ein eigenes Label zu und lassen Sie zunächst nur vertrauenswürdige Branches darauf laufen. Prüfen Sie, ob das ausführende Konto auf den Signierungsschlüsselbund und das Arbeitsverzeichnis zugreifen kann und der Build ohne Dialogfenster durchläuft.
Die Migration ist abgeschlossen, wenn:derselbe Commit mit derselben Xcode-Version und derselben Lockdatei auf dem Knoten ein abrufbares Archiv erzeugt. Eine erfolgreiche Installation der Abhängigkeiten allein reicht nicht als Nachweis für eine vollständige Umgebungsmigration.