Prüfe zuerst Node, Zugangsdaten und lokales Netzwerk, bevor du eine Remote-Sitzung herstellst. Sobald die Verbindung stabil ist, migrierst du Code, Daten, Toolchain und CI schrittweise statt deine lokale Umgebung auf einmal zu kopieren.
Migriere bei der ersten Verbindung noch kein Projekt. Führe zunächst fünf grundlegende Prüfungen durch und stelle sicher, dass Client, Netzwerk und Übergabeinformationen eine stabile Sitzung ermöglichen.
Prüfe, ob die Client-Version geeignet ist, und halte eine alternative Zugriffsmethode bereit. Deaktiviere vor der ersten Sitzung Erweiterungen, die Tastaturzuordnung, Proxy oder Anzeigeskalierung verändern.
Nutze bevorzugt eine kabelgebundene Verbindung oder stabiles WLAN und pausiere große Synchronisierungen sowie lokale Uploads. Bei einem Unternehmensproxy muss SSH-Datenverkehr unverändert bleiben.
Lies Node-Adresse, Benutzernamen und Verbindungsmethode aus der Konsole aus – nicht aus Chatverläufen oder alten Tickets. Bewahre Zugangsdaten ausschließlich im Passwortmanager auf, niemals in Skripten oder Repositories.
Verbinde dich zunächst mit einem Monitor und einer üblichen Skalierung. Erhöhe die Auflösung erst, wenn Text, Cursor und Tastenkürzel funktionieren, damit Anzeigeprobleme nicht mit Netzwerkproblemen verwechselt werden.
Übertrage zunächst nur die Projektliste, Lockfiles und einen kleinen prüfbaren Branch. Mediendateien, alte Caches und Archive folgen erst nach erfolgreicher Verbindungsprüfung in getrennten Chargen.
Teile die erste Sitzung in fünf Schritte auf: Adresse, Verbindung, Zugangsdaten, Eingabe und Anzeige. Jeder Schritt hat eine klare Abschlussbedingung, sodass sich Abweichungen auf die letzte Änderung zurückführen lassen.
Vergleiche Hostname oder Adresse, Benutzernamen und Verbindungsprotokoll mit den Übergabeinformationen der Konsole. Prüfe zuerst, ob der Ziel-Node stimmt, und stelle dann die Sitzung her.
Verbinde dich mit einem Monitor, üblicher Auflösung und Standardbildqualität. Halte die Sitzung einige Minuten aktiv und teste Fensterwechsel, Texteingabe und Dateinavigation.
Lege nach der ersten Anmeldung sofort unabhängige, starke Zugangsdaten fest, aktualisiere den Passwortmanager und entferne die bei der Übergabe verwendeten initialen Zugangsdaten aus dem täglichen Ablauf.
Teste Command, Option, Control, Pfeiltasten sowie gängige deutsche und englische Eingaben. Remote-Client und macOS müssen dieselbe Belegung verwenden.
Erhöhe Auflösung, Skalierung und Bildqualität erst nach einer stabilen Basissitzung. Ändere jeweils nur einen Wert und beobachte Textschärfe, Cursorverzögerung und Netzwerkauslastung.
Führe die drei Pfade in dieser Reihenfolge aus. Dokumentiere pro Abschnitt Eingaben, Aktionen, Prüfergebnisse und Wiederherstellungspunkt, damit Code, Tool-Versionen und Automatisierung nicht gleichzeitig verändert werden.
Code und Konfiguration zuerst, reproduzierbare Caches später; schwer rekonstruierbare Signaturmaterialien und Mediendateien separat prüfen. Teste Pfad und Berechtigungen vor großen Transfers mit einer kleinen Stichprobe.
| Datentyp | Erste Charge | Empfohlene Aktion | Prüfung | Wiederherstellung |
|---|---|---|---|---|
| Code-Repository | Haupt-Repository, Submodule, Lockfiles | Mit einem sauberen Klon beginnen; Arbeitsverzeichnisse mit lokalem Status nicht direkt kopieren | Branches, Commit-Hash, Submodule und nicht verfolgte Dateien prüfen | Remote-Kopie löschen und erneut klonen |
| Build-Cache | Nur bestätigte wiederverwendbare Caches übertragen | Zuerst einen Build ohne Cache ausführen, danach Caches je Tool wiederherstellen | Trefferlogs, Build-Ergebnis und Speicherbelegung vergleichen | Zugehörige Cache-Verzeichnisse leeren und neu erzeugen |
| Signaturmaterial | Die für das Projekt tatsächlich erforderliche Mindestmenge | Über einen kontrollierten verschlüsselten Kanal übertragen; Datei- und Schlüsselbundrechte begrenzen | Signaturprüfung ohne Artefakt-Upload ausführen | Importe entfernen und temporäre Zugriffsrechte widerrufen |
| Medien-Assets | Eine kleine Stichprobe zur vollständigen Ablaufprüfung | Verzeichnisse nach Projekt, Charge und Zweck anlegen; nicht mit Caches mischen | Dateianzahl, Größe und Prüfsummen prüfen | Aktuelle Charge löschen und aus den lokalen Originalen erneut übertragen |
| Große Archive | Index, Manifest und ein Testarchiv | In Teilen übertragen, Status jeder Teilmenge protokollieren und das Zielverzeichnis nicht auf einmal überschreiben | Jede Teilmenge prüfen und entpackte Inhalte stichprobenartig kontrollieren | Nur fehlgeschlagene Teilmengen erneut übertragen, nicht alles wiederholen |
Nicht „Dateien sind übertragen“, sondern: Der Remote-Mac kann aus einem klaren Commit und einer Abhängigkeitsliste ein prüfbares Build-Ergebnis reproduzieren.
Beginne nicht mit der Installation aller üblichen Tools. Orientiere dich an den tatsächlichen Projektabhängigkeiten und reproduziere sie in der Reihenfolge System, Compiler, Kommandozeilentools, Abhängigkeitsverwaltung, Zertifikate und Skripte.
Systemversion, Architektur, freien Speicher und Regionseinstellungen dokumentieren und die Projektanforderungen mit den Systemmöglichkeiten abgleichen.
Systeminformationen archiviertVorgegebene Version, Komponenten beim ersten Start und aktuelles Entwicklerverzeichnis prüfen; nicht von einer temporären Auswahl in der grafischen Oberfläche abhängen.
Version und Pfad stimmen übereinCompiler, SDK, Git, Ruby und weitere benötigte Laufzeiten prüfen und die tatsächlich aufgelösten Pfade dokumentieren.
Befehlsauflösung eindeutigAbhängigkeiten anhand der Lockfiles wiederherstellen, globale Tools von Projektabhängigkeiten trennen und fehlende Komponenten nicht durch lokale Caches verbergen.
Saubere Installation reproduzierbarNur für die aktuelle Aufgabe benötigte Materialien importieren und Schlüsselbundzugriff, Dateirechte sowie Sichtbarkeit für Automatisierungsprozesse prüfen.
Minimaler Umfang bestätigtMit schreibgeschützten Prüfungen beginnen, danach Abhängigkeitsauflösung, Tests und Build ausführen. Skripte dürfen nicht von nicht dokumentierten absoluten lokalen Pfaden abhängen.
Identisches Ergebnis für denselben CommitDie Runner-Anbindung sollte nicht gleichzeitig mit der Toolchain-Migration erfolgen. Bestätige zuerst einen reproduzierbaren Build in der manuellen Sitzung und übernimm anschließend denselben Befehl in den Automatisierungsjob.
Verwende für den Cloud-Mac eine eigene Runner-ID und eigene Labels und begrenze zulässige Repositories sowie Jobtypen. Führe zunächst nur einen Diagnosejob aus, der Systeminformationen ausgibt.
Dokumentiere Versionen und Pfade als normale Umgebungsvariablen. Sensible Werte gehören in einen kontrollierten Geheimnisspeicher. Tokens, private Schlüssel und Signaturmaterial dürfen niemals in Logs erscheinen.
Trenne Quellcode, Abhängigkeitscache, temporäre Ausgaben und endgültige Artefakte. Prüfe vor dem Job den freien Speicher und lösche danach nur reproduzierbare Inhalte.
Der Upload darf nur das vereinbarte Ausgabeverzeichnis lesen. Bewahre außerdem Commit-Hash, Build-Nummer und Prüfinformationen auf, damit temporäre Logs nicht im Lieferpaket landen.
Erfasse den Exit-Code und entferne Sperrdateien, angehaltene Prozesse sowie temporäre Verzeichnisse. Nach dem Sichern der Diagnose-Logs muss der nächste Job aus einem bekannten Zustand starten.
Prüfe mindestens einmal einen Build in einem vollständig neuen Arbeitsverzeichnis, einen erneuten Lauf nach einem Fehler sowie Upload und Prüfung eines Artefakts. Erst wenn alle drei Prüfungen bestanden sind, erweiterst du den Aufgabenbereich.
Die folgenden Prüfungen ändern keine Systemkonfiguration. Setze Host und Benutzernamen zunächst im lokalen Terminal anhand der Übergabeinformationen der Konsole und stelle dann eine SSH-Sitzung her, um System, Architektur, Speicher und Pfade der Entwicklertools zu dokumentieren.
Host, Benutzername, Schlüsselpfad und Token gehören weder in Projektskripte noch in die Versionsverwaltung.
Führe zunächst schreibgeschützte Prüfungen durch und ändere die Toolchain erst nach der Bestandsaufnahme.
export SETMINI_HOST="vom Kontrollpanel bereitgestellte Knotenadresse"
export SETMINI_USER="vom Kontrollpanel bereitgestellter Benutzername"
ssh "${SETMINI_USER}@${SETMINI_HOST}"
hostname
sw_vers
uname -m
df -h /
xcode-select -p
xcodebuild -version
git --version
echo "$SHELL"Ein exklusiver physischer Server bedeutet nicht, dass Zugriffskontrollen entfallen können. Zugangsdaten, Berechtigungen, Bildschirmsperre, Abmeldung und die Bereinigung sensibler Dateien gehören in jede Team-Übergabeliste.
Lege eigene Zugangsdaten für den Node fest und speichere sie im Passwortmanager. Ändere sie sofort bei Teamwechseln, vermutetem Verlust oder ungewöhnlichen Anmeldungen.
Verwende für die tägliche Entwicklung nur die für die Aufgabe erforderlichen Mindestberechtigungen. Beende temporäre Erhöhungen umgehend und hinterlege keine erweiterten Rechte in Automatisierungsskripten.
Sperre die Sitzung auch bei kurzer Abwesenheit. Schließe in gemeinsam genutzten Arbeitsumgebungen zusätzlich die lokale Bildschirmvorschau, damit Remote-Inhalte nicht sichtbar werden.
Beende nach Abschluss der Aufgabe den Remote-Client und die SSH-Sitzung und prüfe, dass keine interaktiven Prozesse oder temporären Portweiterleitungen zurückbleiben.
Entferne temporäre Downloads, Debug-Exporte, unverschlüsselte Archive und nicht mehr benötigtes Signaturmaterial und dokumentiere die Bereinigung.
Wenn du unbekannte Sitzungen, ungewöhnliche Prozesse oder ein Risiko für Zugangsdaten feststellst, sichere zuerst Zeitpunkt und notwendige Logs und reiche anschließend über die Konsole ein Ticket ein.
Ticket über die Konsole erstellenWähle einen exklusiven Apple-Silicon-Mac. Nach Erhalt der Übergabeinformationen führst du Verbindung, Umgebungsdokumentation und CI-Anbindung in der Reihenfolge dieser Seite durch.