Ihre erste Distribution ausrollen

Ihre erste Distribution durchführen

Ihre erste Distribution ausrollen

Sobald die lokalen Checks bestanden sind, folgt der erste echte Rollout.

Wenn divekit doctor oder divekit dev noch ernsthafte Probleme melden, beheben Sie diese zuerst.
Sieht Ihr Setup bereits klar aus und arbeiten Sie in einer sicheren Ziel-Gruppe, kann es losgehen.

Mitglieder bereitstellen

Verteilte Repositories gehören in der Regel Personen. Divekit bietet Ihnen zwei interaktive Wege, sie bereitzustellen:

  1. Vor dem Rollout mit divekit members: ein interaktiver Prompt, in dem Sie Ihre Mitglieder-Eingabe machen. Neue Eingaben werden mit den bereits konfigurierten Mitgliedern zusammengeführt.
  2. Während des Rollouts: Wenn noch keine Mitglieder konfiguriert sind, öffnet divekit distribute dieselbe interaktive Mitglieder-Eingabe, bevor es irgendetwas anlegt.

In beiden Fällen speichert Divekit die Mitglieder-Eingabe als Datei mit Zeitstempel in Ihrem Divekit-Verzeichnis auf Benutzerebene (~/.divekit/members/) — nicht im Projekt — und referenziert sie aus config.json über einen members.path-Eintrag wie $DIVEKIT_MEMBERS/2026-07-16_10-24-55_M0_members.json. Die Berechtigungsstufe kommt aus members.permissions in config.json.

Die Mitglieder-Eingabe entscheidet auch, wie viele Repositories entstehen: Jede Zeile wird zu einer Gruppe, und jede Gruppe bekommt genau ein generiertes Repository. Zwei Zeilen erzeugen also zwei Repositories.

Eine Zeile mit mehreren kommagetrennten Accounts, etwa alice,bob, bildet ein Team, das sich ein Repository teilt. Verwenden Sie reine GitLab-Benutzernamen — kein @-Präfix, keine E-Mail-Adressen.

Wenn Sie bereits eine Mitgliederliste als Datei haben, überspringt divekit distribute --members-file <pfad> die interaktive Mitglieder-Eingabe. Sind zusätzlich schon Mitglieder konfiguriert, fragt Divekit trotzdem zuerst, was damit passieren soll.
Halten Sie diese Datei außerhalb des Projektordners: Alles im Projekt wird verteilt — eine Mitgliederliste im Projektwurzelverzeichnis würde also in jedem generierten Repository landen.

Für diesen ersten Rollout brauchen Sie keine echte Kursliste: Zwei Zeilen mit einem sicheren Test-Account reichen und geben Ihnen zwei Repositories zum Vergleichen.
Wenn Sie beim lokalen Validierungslauf bereits Mitglieder eingegeben haben, sind diese noch konfiguriert — der Rollout wird anbieten, sie zu behalten.

Die konfigurierten Mitglieder können Sie jederzeit einsehen:

divekit members list -d M0
$ divekit members list -d M0

Members for M0

  source    $DIVEKIT_MEMBERS/2026-07-16_10-24-55_M0_members.json
  resolved  /home/your-name/.divekit/members/2026-07-16_10-24-55_M0_members.json

  b8520e99-2bad-c0de-b61c-1249a10f7a5a  student-one
  a70decaf-bad7-4c95-b211-d0bc95f48204  student-two

Die resolved-Zeile zeigt, wo die Mitglieder-Eingabe auf Ihrem Rechner tatsächlich liegt, und jede Zeile darunter ordnet eine Gruppen-UUID ihren Mitgliedern zu.

Die echte Distribution ausführen

Direkt vor diesem Schritt führen manche Teams gern noch eine zusätzliche lokale Vorschau aus:

divekit distribute -d M0 --provider local

Das kann nützlich sein, wenn Sie echte generierte Dateien wollen, bevor Sie GitLab anfassen.

Wenn M0 Ihre einzige Distribution ist, können Sie einfach ausführen:

divekit distribute

Wenn Sie explizit sein möchten, ist divekit distribute -d M0 genauso in Ordnung.

Das ist der Schritt, in dem Divekit das vorbereitete Origin-Repository in individualisierte Remote-Repositories verwandelt.

So sieht ein gesunder Lauf aus

$ divekit distribute -d M0

Configured members found. Choose action

●    Keep   Use 2 configured members
○    Add
○    Edit
○    Fresh

↑/↓ to navigate • enter to select • esc to cancel

┃  # Distribution Plan
┃  https://gitlab.git.nrw/your-group
┃  └─ work
┃     ├─ M0-b8520e99-2bad-c0de-b61c-1249a10f7a5a
┃     └─ M0-a70decaf-bad7-4c95-b211-d0bc95f48204

Proceed with distribution?

  Yes      No

Completed: 4/4

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

Drei Dinge in diesem Ablauf sind lesenswert:

  • der Configured members found-Prompt erscheint, weil bereits Mitglieder konfiguriert sind — Keep verwendet sie unverändert; wären keine konfiguriert, würde sich hier stattdessen die Mitglieder-Eingabe öffnen
  • der Distribution Plan ist Ihr letzter Kontrollpunkt, bevor irgendetwas auf GitLab entsteht: Prüfen Sie Ziel-Gruppe und Repository-Namen, bevor Sie bestätigen
  • die letzten Zeilen bestätigen, wie viele Gruppen ein Repository erhalten haben

Was während des Rollouts passiert

In einem typischen Lauf macht Divekit Folgendes:

  • liest .divekit/distributions/M0/config.json
  • erstellt die Ziel-Repositories
  • individualisiert die Inhalte
  • weist Mitglieder und Berechtigungen zu
  • schreibt Zustandsdateien
.divekit/distributions/M0/individuals.json
.divekit/distributions/M0/remotes.json

So sieht Erfolg aus

Führen Sie aus:

divekit overview -d M0

Öffnen Sie dann die Ziel-GitLab-Gruppe und bestätigen Sie:

  • Repositories existieren
  • die Repository-Namen folgen dem Default-Muster {{distribution}}-{{uuid}}, hier also M0-<uuid> — ein optionaler name-Schlüssel in config.json könnte diesen Default überschreiben
  • die erwarteten Mitglieder wurden zugewiesen
  • die Inhalte unterscheiden sich dort, wo Sie Variation erwartet haben

Beispielhafte Form eines gesunden Overviews:

$ divekit overview -d M0

From cache (2026-07-16 10:31)

b8520e99-2bad-c0de-b61c-1249a10f7a5a [student-one]
└─ work https://gitlab.git.nrw/projects/1234

a70decaf-bad7-4c95-b211-d0bc95f48204 [student-two]
└─ work https://gitlab.git.nrw/projects/1235

Jeder Eintrag zeigt die UUID, die zugewiesenen Mitglieder in Klammern und das erstellte Repository als Link.
Die From cache (...)-Zeile bedeutet, dass die Mitgliederdaten aus der zwischengespeicherten Members-Datei stammen — mit --no-cache holen Sie sie frisch von GitLab.

Wenn die UUIDs oder Repository-Namen hier nicht Ihren Erwartungen entsprechen, halten Sie an und inspizieren Sie, bevor Sie erneut verteilen.

Schnelle Einordnung

Was Sie sehen Wie Sie es lesen Was als Nächstes zu tun ist
erwartete UUIDs und Repository-Namen erscheinen in overview und GitLab Normaler Erfolg beim ersten Rollout Weiter zur Zustandsinspektion
Repositories existieren, aber die Namen sehen falsch aus Config hat vermutlich funktioniert, die Benennung nicht Namen folgen standardmäßig M0-<uuid>; prüfen Sie den Distributionsnamen und einen eventuellen name-Override in config.json
Repositories existieren, aber erwartete Mitglieder fehlen Rollout teilweise erfolgreich, Mitgliedschaft nicht Die konfigurierten Mitglieder mit divekit members list prüfen
remote wurde nichts erstellt Rollout ist nicht wie erwartet durchgelaufen Anhalten und inspizieren, bevor Sie es erneut versuchen

Typische Fehler

Was Sie versuchen können
Die Terminal-Ausgabe ist hilfreich, aber individuals.json und remotes.json sind der echte Beleg dafür, was passiert ist.
Was Sie versuchen können
GitLab zeigt die Remote-Wirkung. Die lokalen Zustandsdateien zeigen, was Divekit für den Distributionszustand hält.
Was Sie versuchen können
Nach dem ersten Rollout: innehalten und inspizieren.

Check

Nach der ersten echten Distribution:

  1. divekit overview -d M0 ausführen
  2. die erstellten Repositories in GitLab verifizieren
Vorschlag zur Antwort
Vergleichen Sie divekit overview -d M0 mit der Ziel-GitLab-Gruppe: Dieselben UUIDs und Mitglieder erscheinen in beiden. Prüfen Sie in GitLab außerdem, dass die Repository-Namen dem erwarteten Muster M0-<uuid> folgen.
Vorschlag zur Antwort
Das Kommandoergebnis sagt nur, dass der Rollout gelaufen ist. Öffnen Sie die erstellten Repositories in GitLab und prüfen Sie, dass die erwarteten Accounts tatsächlich die beabsichtigte Berechtigungsstufe haben.