Lokal validieren vor dem Rollout

Eine echte Distribution erstellt Remote-Repositories und weist Mitglieder zu — bevor es so weit ist, lohnt sich eine lokale Validierung des Setups.

Für diesen Kurs heißt das:

• die Umgebung mit divekit doctor prüfen
• optional ein lokales Distributionsergebnis mit divekit distribute -d M0 --provider local erzeugen

Das Setup validieren

Schritt 1: doctor erneut ausführen

Prüfen Sie das Setup vor dem Rollout noch einmal:

divekit doctor

In dieser Phase sollte doctor keine fehlende Authentifizierung mehr bemängeln. Wenn er noch offensichtliche Probleme meldet, beheben Sie diese zuerst.

Schritt 2: optional lokal verteilen

Wenn Sie ein echtes generiertes Ergebnis inspizieren möchten, bevor Sie GitLab anfassen, führen Sie aus:

divekit distribute -d M0 --provider local

Divekit unterstützt zwei Provider für distribute: gitlab (der Default) und local.
Der lokale Provider schreibt die tatsächlich generierten Ausgaben in Ihr Dateisystem, statt irgendetwas auf GitLab anzulegen.

Zuerst öffnet sich die Mitglieder-Eingabe

Auch eine lokale Distribution muss wissen, wie viele Repositories sie generieren soll.
Wenn noch keine Mitglieder konfiguriert sind, öffnet Divekit seine interaktive Mitglieder-Eingabe, bevor es irgendetwas generiert:

Member Name Input
Write one username per line, or comma-separate members that share one repository.

╭─────────────────────────────────────────────────────────────
│
│   1 student-one
│   2 student-two
│
╰─────────────────────────────────────────────────────────────

ctrl+s/d finish • ctrl+e external editor • esc/ctrl+c cancel

Für diesen lokalen Test reichen zwei Zeilen mit einem sicheren Test-Account — jede Zeile wird zu einem generierten Repository.
Die nächste Lektion erklärt die Mitglieder-Eingabe im Detail. Was Sie hier eingeben, wird gespeichert und für den echten Rollout wiederverwendet.

Den Distribution Plan bestätigen

Divekit zeigt dann, was es gleich generiert, und fragt nach Bestätigung:

┃  # Distribution Plan
┃
┃  file://.divekit/local-data/M0/local/20260716-102455_311/work
┃  └─ work
┃     ├─ M0-b8520e99-2bad-c0de-b61c-1249a10f7a5a/repo
┃     └─ M0-a70decaf-bad7-4c95-b211-d0bc95f48204/repo

Proceed with distribution?

  Yes      No

Completed: 4/4

Distribution completed successfully!
Created repositories for 2 group(s)

Das generierte Ergebnis öffnen

Das lokale Ergebnis landet unter .divekit/local-data/M0/local/<timestamp>_<groupId>/.
Sein work/-Ordner enthält ein Verzeichnis pro generiertem Repository, Sie können die individualisierten Dateien also direkt öffnen:

.divekit/local-data/M0/local/20260716-102455_311/
├── individuals.json
├── remotes.json
└── work/
    ├── M0-b8520e99-2bad-c0de-b61c-1249a10f7a5a/
    │   ├── members.json
    │   ├── variables.json
    │   └── repo/
    │       ├── README.md
    │       └── src/
    │           └── Car.java
    └── M0-a70decaf-bad7-4c95-b211-d0bc95f48204/
        └── ... (gleiche Struktur, eventuell mit einem anderen Fahrzeug)

Das ist der erste Moment, in dem Sie die Individualisierung mit eigenen Augen sehen können.
Öffnen Sie eine generierte src/-Datei und vergleichen Sie sie mit Ihrer Vorlage:

public class Car {
    public String kind() {
        return "Car";
    }
}

Jedes $Vehicle$ wurde konsistent ersetzt — im Dateinamen und im Inhalt.

Zwei Details sind gut zu wissen:

• die Variante pro Repository wird zufällig gewählt, zwei Repositories können also auch dasselbe Fahrzeug bekommen — das ist normal, und individuals.json hält fest, was gewählt wurde
• der lokale Lauf schreibt seine eigenen individuals.json und remotes.json in diesen Ordner mit Zeitstempel statt nach .divekit/distributions/M0/ — die Zustandsdateien dort stammen von späteren Rollouts gegen GitLab

Worauf Sie achten sollten

Achten Sie auf diese Signale:

• doctor meldet eine gesunde Umgebung
• eine lokale Distribution läuft sauber durch, falls Sie sie ausgeführt haben
• das generierte lokale Ergebnis passt zu Ihrer Vorlage und Individualisierung, bevor Sie Remote-Systeme anfassen

Wenn sich Ihre Individualisierung an diesem Punkt noch unklar anfühlt, gehen Sie zurück zur vorherigen Lektion und führen Sie dort divekit dev erneut aus, bevor Sie den echten Rollout starten.

Schnelle Einordnung

Typische Fehler

divekit config hosts list

Check

Führen Sie zuerst dieses Kommando aus:

divekit doctor

Wenn Sie vor GitLab noch einen realistischeren Check möchten, führen Sie außerdem aus:

divekit distribute -d M0 --provider local