Generierten Zustand inspizieren

Zwei Zustandsdateien erklären, was Divekit nach dem Rollout tatsächlich festgehalten hat.

In dieser Lektion geht es nicht um Fehlersuche, sondern darum, den ersten Rollout wirklich zu verstehen: welches Repository welche Variante bekommen hat, wo auf GitLab jedes Repository gelandet ist, wer zugewiesen wurde — und dass alle genau die beabsichtigten Berechtigungen haben.

Die Zustandsdateien und ein Blick in GitLab erzählen diese Geschichte gemeinsam.

Die zwei wichtigsten generierten Dateien

Inspizieren Sie nach der Distribution:

.divekit/distributions/M0/individuals.json
.divekit/distributions/M0/remotes.json

Die Mitglieder-Eingabe wird separat in Ihrem Divekit-Verzeichnis auf Benutzerebene (~/.divekit/members/) gespeichert und aus config.json referenziert. Für diese Einsteigerlektion liegt der Inspektionsfokus auf individuals.json und remotes.json.

Was Sie inspizieren sollten

Was Sie in individuals.json inspizieren sollten

Fragen Sie:

• taucht jede generierte UUID hier auf?
• hat jede UUID eine konkrete Auswahl?
• passen die gewählten Optionen zu den Möglichkeiten aus individualization.json?

Diese Datei sagt Ihnen, ob die Individualisierungslogik tatsächlich konkrete Ergebnisse produziert hat.

Beispielhafte Form:

{
  "version": "2.0",
  "individuals": [
    {
      "uuid": "b8520e99-2bad-c0de-b61c-1249a10f7a5a",
      "selection": {
        "objects": {
          "Vehicle": "Car"
        },
        "relations": {},
        "logic": {}
      }
    },
    {
      "uuid": "a70decaf-bad7-4c95-b211-d0bc95f48204",
      "selection": {
        "objects": {
          "Vehicle": "Bike"
        },
        "relations": {},
        "logic": {}
      }
    }
  ]
}

Was Sie in remotes.json inspizieren sollten

Fragen Sie:

• taucht jede erwartete UUID hier auf?
• ist jeder UUID ein erstelltes Remote-Repository zugeordnet?
• sieht der Remote-Zustand vollständig genug für Folgekommandos aus?

Diese Datei sagt Ihnen, wie Divekit das Remote-Ergebnis operativ festgehalten hat.
project_path und web_url beantworten die Frage „wo ist es gelandet?" präzise — je nach Setup kann das auch eine Untergruppe Ihrer Ziel-Gruppe sein. Das ist der schnellste Weg, jedes generierte Repository zu finden.

Beispielhafte Form:

{
  "targets": {
    "work": {
      "remotes": [
        {
          "uuid": "b8520e99-2bad-c0de-b61c-1249a10f7a5a",
          "project_id": 1234,
          "project_path": "your-group/M0-b8520e99-2bad-c0de-b61c-1249a10f7a5a",
          "web_url": "https://gitlab.git.nrw/your-group/M0-b8520e99-2bad-c0de-b61c-1249a10f7a5a",
          "pages_url": "https://m0-b8520e99-2bad-c0de-b61c-1249a10f7a5a-3f9a1c.pages.git.nrw"
        },
        {
          "uuid": "a70decaf-bad7-4c95-b211-d0bc95f48204",
          "project_id": 1235,
          "project_path": "your-group/M0-a70decaf-bad7-4c95-b211-d0bc95f48204",
          "web_url": "https://gitlab.git.nrw/your-group/M0-a70decaf-bad7-4c95-b211-d0bc95f48204",
          "pages_url": "https://m0-a70decaf-bad7-4c95-b211-d0bc95f48204-c6de4c.pages.git.nrw"
        }
      ]
    }
  }
}

Nützliches Inspektionskommando

Führen Sie aus:

divekit overview -d M0

Dieses Kommando hilft Ihnen zu vergleichen:

• den generierten Zustand
• die übergeordnete Repository-Übersicht
• das sichtbare GitLab-Ergebnis

Zeigt der Vergleich etwas Unerwartetes, fangen Sie noch nicht an zu reparieren — die nächste Lektion gibt Ihnen genau dafür eine klare Troubleshooting-Reihenfolge.

Schnelle Verifikation in GitLab

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

• die Repositories existieren dort, wo Sie sie erwarten — vergleichen Sie mit project_path aus remotes.json
• die Repository-Namen enthalten die sichtbaren UUIDs
• die erwarteten Mitglieder wurden zugewiesen

Öffnen Sie danach die Mitgliederliste eines Repositorys (Manage → Members) und prüfen Sie die Rolle.
In diesem Kurs sollte sie reporter sein — Lesezugriff, nicht mehr. Dass Mitglieder genau die beabsichtigte Berechtigungsstufe haben und keine höhere, gehört zu einem korrekten Rollout dazu.

Die Individualisierung sehen

Das ist der Moment, auf den der ganze Workflow hingearbeitet hat.

Öffnen Sie den src/-Ordner beider generierter Repositories und vergleichen Sie sie:

• ein Repository enthält zum Beispiel Car.java mit public class Car
• das andere enthält Bike.java mit public class Bike

Ein Origin hat unterschiedliche, in sich konsistente Repositories erzeugt — und individuals.json hat exakt festgehalten, welches Repository welche Variante bekommen hat.

Die Variante pro Repository wird zufällig gewählt — bei nur drei Optionen können zwei Repositories also auch dasselbe Fahrzeug bekommen.
Das ist kein Fehler: individuals.json ist die maßgebliche Aufzeichnung dessen, was jedes Repository bekommen hat.

Check

Erledigen Sie nach der ersten echten Distribution alle folgenden Punkte:

1. individuals.json öffnen
2. remotes.json öffnen
3. divekit overview -d M0 ausführen