Logo

Abschließendes Mini-Projekt

Abschlussübung

Abschließendes Mini-Projekt

Diese Abschlussübung lässt Sie den kompletten Einsteiger-Workflow wiederholen, ohne die früheren Lektionen Zeile für Zeile nachzulesen.

Erstellen und verteilen Sie eine winzige Aufgabe namens shape-workshop mit:

  • einer Distribution namens WS1
  • mindestens zwei generierten Repositories
  • einer platzhalterbasierten Vorlage
  • einer individualization.json mit zwei einfachen Variationsachsen
  • einer erfolgreichen echten Distribution
  • einem verifizierten Ergebnis anhand von Zustandsdateien und Overview-Kommandos

Erfolgskriterien

Am Ende der Übung sollten Sie Folgendes haben:

  • ein neues Origin-Repository
  • eine konfigurierte Distribution
  • eine funktionierende Individualisierungsdatei für Shape und Color
  • eine generierte individuals.json
  • eine generierte remotes.json
  • ein verifiziertes Remote-Ergebnis auf Ihrem GitLab-Ziel

Bevor Sie starten

Verwenden Sie den Host-Alias wieder, den Sie früher im Kurs konfiguriert haben.

Für die Übung brauchen Sie:

  • eine GitLab-Gruppe oder einen Namespace, in dem Sie die neuen Repositories anlegen dürfen
  • eine konkrete groupId für dieses Ziel
  • mindestens einen echten Account, mit dem Sie die Mitgliederzuweisung testen können

Wenn Sie nur einen sicheren Test-Account haben, verwenden Sie ihn auf zwei Zeilen der Mitglieder-Eingabe — jede Zeile wird zu einer eigenen Gruppe mit eigenem generiertem Repository.

Bauen Sie eine minimale Aufgabe rund um die Platzhalter $Shape$ und $Color$.

Mögliche Variationswerte:

  • Circle
  • Square
  • Triangle

Mögliche Farbwerte:

  • Red
  • Blue
  • Green

Vorschlag für die Datei

Ihre Vorlage kann so klein sein wie diese — nehmen Sie die Platzhalter auch in den Dateinamen auf, zum Beispiel src/$Color$$Shape$.java:

public class $Color$$Shape$ {
    public String label() {
        return "$Color$ $Shape$";
    }
}

Eine winzige README reicht.

Vorgeschlagene Arbeitsreihenfolge

Erledigen Sie Folgendes, ohne den früheren Lektionstext Zeile für Zeile zu kopieren:

  1. das Projektverzeichnis anlegen
  2. divekit init mit dem Distributionsnamen WS1 ausführen
  3. eine winzige platzhalterbasierte Quelldatei erstellen
  4. config.json prüfen: Sie sollte auf Ihren echten Host-Alias und Ihre echte groupId zeigen — das Standard-Namensmuster hält die UUID bereits sichtbar
  5. mit divekit dev prüfen, welche Platzhalter noch Individualisierung brauchen, und das Grundgerüst dann mit divekit dev --write-individualization anlegen lassen
  6. individualization.json prüfen oder verfeinern: Sie sollte Shape und Color als Objekt-IDs enthalten, jeweils mit eigenen kinds
  7. divekit dev erneut ausführen
  8. divekit doctor ausführen
  9. das Test-Mitglied mit divekit members bereitstellen, oder es eingeben, wenn divekit distribute danach fragt
  10. optional divekit distribute -d WS1 --provider local ausführen
  11. divekit distribute -d WS1 ausführen
  12. individuals.json und remotes.json inspizieren
  13. divekit overview -d WS1 ausführen

Ihr Ergebnis verifizieren

Bevor Sie die Übung als erledigt markieren, verifizieren Sie alle folgenden Punkte:

  • divekit doctor zeigt kein blockierendes Setup-Problem
  • divekit dev zeigt keine unaufgelösten Platzhalter, die Sie noch definieren müssen
  • falls Sie divekit distribute -d WS1 --provider local verwendet haben, sah das generierte lokale Ergebnis korrekt aus
  • divekit distribute -d WS1 erstellt die erwarteten Repositories
  • individuals.json enthält jede UUID, die Sie geplant haben
  • individuals.json hält eine konkrete Wahl sowohl für Shape als auch für Color fest
  • remotes.json hält jedes erstellte Remote-Repository fest
  • Ihr Test-Mitglied ist auf den erstellten Repositories in GitLab sichtbar
  • divekit overview -d WS1 stimmt mit dem sichtbaren Ergebnis in GitLab überein

Wenn einer dieser Checks fehlschlägt, fangen Sie nicht sofort von vorn an. Verwenden Sie die Troubleshooting-Reihenfolge aus der vorherigen Lektion wieder.

Check

Starke Antwort
Setup-Dateien wie config.json und individualization.json sind die Dateien, die Sie prüfen und bearbeiten, um den Rollout zu definieren. Zustandsdateien wie individuals.json und remotes.json werden von Divekit generiert und halten fest, was der Rollout tatsächlich produziert hat.
Starke Antwort
divekit doctor ist oft die klarste Antwort, weil es blockierende Setup-Probleme vor dem echten Rollout aufdeckt. divekit dev gibt zusätzliche Sicherheit, indem es bestätigt, dass die Platzhalter vollständig definiert sind, und divekit distribute -d WS1 --provider local kann ein realistisches Ergebnis zeigen, ohne das echte GitLab-Ziel anzufassen.
Starke Antwort
Beginnen Sie mit individuals.json, wenn die UUID mit dem falschen generierten Individual oder den falschen Variationsentscheidungen verknüpft zu sein scheint. Inspizieren Sie zuerst remotes.json, wenn das Problem ist, in welchem Remote-Repository diese UUID gelandet ist. In der Praxis ist der Blick in beide Dateien oft der schnellste Weg, die vollständige Zuordnung zu bestätigen.
Starke Antwort
Es sollte bestätigen, dass weder für Shape noch für Color unaufgelöste Platzhalter übrig sind.

Wenn alle Checks bestehen, haben Sie den Einsteigerkurs abgeschlossen: von einem einfachen Projektordner zu einer verifizierten, individualisierten Distribution.

Aufräumen

Die Übungs-Repositories haben ihren Zweck erfüllt — löschen Sie sie von der geteilten GitLab-Instanz:

divekit purge -d WS1

Divekit listet die Repositories in der Ziel-Gruppe, zeigt einen Löschplan und fragt nach Bestätigung.

Denken Sie an die Warnung aus der Troubleshooting-Lektion: Der Plan umfasst alles in der Ziel-Gruppe, nicht nur das, was diese Distribution erstellt hat. Lesen Sie ihn, bevor Sie bestätigen — listet er mehr als Ihre WS1-Übungs-Repositories, antworten Sie mit No und prüfen Sie, auf welche Gruppe Sie zielen.