Willkommen und mentales Modell

Diese Lektion führt die drei Grundbegriffe ein, mit denen der ganze Kurs arbeitet: Origin-Repository, Distribution und Individualisierung.

Die Kernidee von Divekit: Es startet mit einem lokalen Origin-Repository — so heißt das Quellprojekt, das Ihre Vorlage enthält — und erzeugt daraus individualisierte Remote-Repositories.

Diese Projektstruktur bauen Sie später im Kurs Schritt für Schritt auf.
An dieser Stelle ist sie nur ein mentales Modell — noch keine Aufgabe, diese Dateien bereits anzulegen.

Eine vereinfachte Sicht sieht so aus:

vehicle-workshop/
├── .divekit/
│   ├── individualization.json
│   └── distributions/
│       └── M0/
│           └── config.json
├── src/
│   └── $Vehicle$.java
└── README.md

Die wichtigste Idee ist diese:

• Ihr Origin-Repository ist die Quelle
• Ihre Distribution ist ein benanntes Rollout-Setup innerhalb dieses Repositorys
• Ihre Individualisierungsdatei beschreibt, was zwischen den generierten Repositories variieren darf

Origin-Repository

Das Origin-Repository ist das lokale Quell-Repository, das Ihre Aufgaben-Vorlage und die Divekit-Konfiguration enthält.

Für Divekit selbst brauchen Sie kein git: Es spricht mit GitLab über dessen API, ein einfacher lokaler Ordner reicht also für diesen Kurs.
Das Projekt trotzdem als git-Repository zu führen, ist good practice — Divekit respektiert dann zum Beispiel Ihre .gitignore beim Verteilen.

Distribution

Eine Distribution ist ein benanntes Setup unterhalb von .divekit/distributions/<name>/.

Sie enthält die Konfiguration für einen Rollout. In diesem Kurs verwenden wir den Distributionsnamen M0.

Individualisierungsdatei

Für diesen Kurs ist individualization.json die zentrale Datei.

Sie definiert, was zwischen den verteilten Repositories variieren darf.

Für den Einsteiger-Workflow nutzen Sie nur deren Variationsteil.
Der Rest der Datei kann minimal bleiben, weil Divekit bereits sinnvolle Defaults mitbringt.

Die Beispielidee:

• Repository A bekommt Car
• Repository B bekommt Bike
• Repository C bekommt Plane

Workflow

Für diesen Kurs sieht der Workflow so aus:

1. Divekit installieren
2. GitLab-Host und Token konfigurieren
3. Projektordner anlegen oder betreten
4. divekit init ausführen
5. die generierte config.json prüfen
6. unaufgelöste Platzhalter mit divekit dev prüfen und sie dann mit divekit dev --write-individualization ins Grundgerüst schreiben lassen
7. individualization.json prüfen oder verfeinern
8. das Setup lokal validieren
9. Mitglieder mit divekit members bereitstellen, oder sie eingeben, wenn ein Distributionslauf danach fragt — die optionale lokale Validierung in Schritt 8 zählt bereits
10. den echten Rollout mit divekit distribute ausführen
11. anschließend den generierten Zustand inspizieren

Sie können all das gefahrlos üben: Vor Schritt 10 wird nichts auf GitLab angelegt.
doctor, der Dev-Scan und --provider local bleiben auf Ihrem Rechner — und divekit purge kann Test-Repositories hinterher wieder entfernen.

Beispiel

Wir verwenden eine kleine Beispielaufgabe namens vehicle-workshop.

Sie ist bewusst minimal:

• ein Platzhalter: $Vehicle$
• eine Distribution: M0
• ein einfaches Variationsobjekt: Vehicle
• ein paar mögliche Ersetzungen wie Car, Bike und Plane

So bleibt der Kurs auf den Workflow fokussiert statt auf fachliche Komplexität.

Check

Diese Fragen sollten Sie jetzt beantworten können: