Seminar DatoCMS: Entwicklungsworkflow mit CLI, Environments und Migrationen

Schemaänderungen werden wie Code behandelt: mit Profilen, Sandbox-Environments, versionierten Migrationen, generierten Typen, Tests, Promotion, Wartungsmodus, CI/CD und dokumentiertem Rückfallweg. Das Seminar setzt den vollständigen Ablauf mehrfach praktisch um.

Inhaltsübersicht

Kapitelinhaltsverzeichnis

• Lernziele und Einsatzbereiche
• Vorbereitung und Arbeitsweise
• Seminarinhalte
• Praktische Übungen und Anwendung

Lernziele und Einsatzbereiche

Kapitelinhaltsverzeichnis

• Kompetenzziele
• Typische Einsatzszenarien
• Abgrenzung und Schwerpunkt

Kompetenzziele

Die Inhalte sind auf unmittelbar anwendbare, prüfbare Kompetenzen ausgerichtet.

• CLI und Projektprofile reproduzierbar in einem Repository einrichten.
• Schemaänderungen als versionierte, testbare Migrationen entwickeln.
• Sandbox- und Primary-Environments mit klaren Promotionregeln betreiben.
• CI/CD, Typgenerierung, Wartungsmodus und Rückfallverfahren verbinden.

Typische Einsatzszenarien

Das Seminar eignet sich insbesondere für die folgenden Projekt- und Betriebssituationen.

• Kontrollierte Weiterentwicklung eines produktiven Schemas.
• Synchronisation von Blueprint- und Kundenprojekten.
• Parallele Featureentwicklung ohne direkte Änderungen am Primary-Environment.

Abgrenzung und Schwerpunkt

Die fachliche Tiefe wird durch folgende Grenzen bewusst fokussiert.

• Inhaltsmigrationen werden nur soweit behandelt, wie sie an Schemaänderungen gekoppelt sind.
• Allgemeine Git- und CI-Grundlagen werden vorausgesetzt.
• Planabhängige Environment-Funktionen werden anhand der verfügbaren Schulungsumgebung geübt.

Vorbereitung und Arbeitsweise

Kapitelinhaltsverzeichnis

• Zielgruppen
• Vorkenntnisse und Schulungsumgebung
• Didaktisches Vorgehen
• Qualitäts- und Abnahmekriterien

Zielgruppen

Entwicklung, technische Architektur, DevOps, Plattformbetrieb und Teams mit mehreren DatoCMS-Projekten oder Umgebungen.

Vorkenntnisse und Schulungsumgebung

JavaScript- oder TypeScript-Praxis, Versionsverwaltung und Kommandozeile. Grundkenntnisse der DatoCMS-Schemamodellierung sind erforderlich.

1. Schritt 1: Zugänge, Rollen und Schulungsprojekt vor Seminarbeginn kontrollieren.
2. Schritt 2: Beispieldaten, Assets, Quellmaterial oder Codebasis entsprechend dem Seminarthema bereitstellen.
3. Schritt 3: Ausgangszustand dokumentieren, damit Übungen wiederholt und Abweichungen eindeutig bewertet werden können.

Didaktisches Vorgehen

Kurze Fachblöcke werden unmittelbar mit Demonstrationen, geführten Arbeitsschritten, eigenständigen Laborphasen und kontrollierten Fehlerfällen verbunden.

1. Schritt 1: Ausgangsproblem und gewünschtes Sollverhalten präzisieren.
2. Schritt 2: Konfiguration oder Implementierung in kleinen, überprüfbaren Schritten ausführen.
3. Schritt 3: Normalfall, Grenzfall und mindestens einen Fehlerfall testen.
4. Schritt 4: Nachweis, Betriebsregel oder Checkliste aus dem Übungsergebnis ableiten.

Qualitäts- und Abnahmekriterien

• Konfigurationen und Arbeitsschritte sind reproduzierbar dokumentiert.
• Berechtigungen, Datenstände und Environments sind eindeutig voneinander getrennt.
• Positive und negative Testfälle besitzen ein erwartetes und nachvollziehbares Ergebnis.
• Fehlerzustände führen zu einer kontrollierten Diagnose und einem definierten Wiederanlauf.

Seminarinhalte

Kapitelinhaltsverzeichnis

• CLI-Installation, Anmeldung und Projektlink
• Primary- und Sandbox-Environments
• Schema-Type-Generation
• Migrationen anlegen und strukturieren
• Idempotenz und Datenverträglichkeit
• Testen in der Sandbox
• Promotion und Wartungsmodus
• CI/CD und automatische Prüfungen
• Rollback und Mehrprojekt-Synchronisation

CLI-Installation, Anmeldung und Projektlink

Lokale Konfiguration wird reproduzierbar und ohne fest eingebettete Geheimnisse aufgebaut.

1. Schritt 1: CLI-Version und Laufzeitvoraussetzungen prüfen.
2. Schritt 2: Projekt sicher anmelden und Repository verknüpfen.
3. Schritt 3: Konfigurationsdatei, Profile und Geheimnisgrenzen dokumentieren.

Primary- und Sandbox-Environments

Environments werden wie Entwicklungszweige mit klarer Eigentümerschaft und Lebensdauer behandelt.

1. Schritt 1: Primary-Zustand und geplantes Feature erfassen.
2. Schritt 2: Sandbox mit eindeutiger Benennung und Verantwortlichem erzeugen.
3. Schritt 3: Lebenszyklus für Aktualisierung, Promotion oder Löschung festlegen.

Schema-Type-Generation

Generierte Typen machen Schemaänderungen in Automatisierungen und Integrationen früh sichtbar.

1. Schritt 1: Typdefinition aus dem aktuellen Schema erzeugen.
2. Schritt 2: Änderungen in der Versionsverwaltung vergleichen.
3. Schritt 3: Kompilierung und betroffene CMA-Skripte gegen die Typen prüfen.

Migrationen anlegen und strukturieren

Jede Migration beschreibt eine begrenzte, nachvollziehbare und wiederholbare Schemaänderung.

1. Schritt 1: Änderungsziel und Abhängigkeiten als Ticket oder Notiz festhalten.
2. Schritt 2: Neue Migrationsdatei mit eindeutiger Reihenfolge erzeugen.
3. Schritt 3: Vorbedingungen, Operationen und Nachkontrollen implementieren.

Idempotenz und Datenverträglichkeit

Migrationen berücksichtigen vorhandene Daten, Teilstände und mögliche Wiederholung.

1. Schritt 1: Bestehendes Schema und Datenrisiken vor Ausführung prüfen.
2. Schritt 2: Operationen mit Existenz- oder Zustandsprüfungen absichern.
3. Schritt 3: Zweiten Lauf beziehungsweise bereits angewandten Zustand testen.

Testen in der Sandbox

Schema, Daten, Frontend und Automatisierungen werden gemeinsam gegen die migrierte Sandbox geprüft.

1. Schritt 1: Frische Sandbox aus geeignetem Ausgangszustand erstellen.
2. Schritt 2: Ausstehende Migrationen ausführen und Protokoll prüfen.
3. Schritt 3: API-Queries, Redaktion und Frontend-Smoke-Tests durchführen.

Promotion und Wartungsmodus

Der Wechsel zum neuen Primary folgt einer kontrollierten Sperr-, Test- und Freigabesequenz.

1. Schritt 1: Schreibaktivität und Releasefenster abstimmen.
2. Schritt 2: Wartungsmodus beziehungsweise redaktionelle Sperre aktivieren.
3. Schritt 3: Aktuelle Sandbox migrieren, testen, promoten und Freigabe protokollieren.

CI/CD und automatische Prüfungen

Pipeline-Schritte verhindern, dass ungeprüfte oder fehlende Migrationen unbemerkt ausgeliefert werden.

1. Schritt 1: Linting, Typprüfung und Dry-Run-nahe Kontrollen definieren.
2. Schritt 2: Migrationen und Frontendtests in einer isolierten Umgebung ausführen.
3. Schritt 3: Freigabegate und Artefaktprotokoll in die Pipeline integrieren.

Rollback und Mehrprojekt-Synchronisation

Rückfall wird über Datenstand, Gegenmigration oder Environment-Wechsel bewusst geplant.

1. Schritt 1: Rückfalloption je Änderungsart festlegen.
2. Schritt 2: Backup-, Export- oder altes Environment als Sicherung prüfen.
3. Schritt 3: Änderungen auf zweites Projekt übertragen und Abweichungen kontrollieren.

Praktische Übungen und Anwendung

Kapitelinhaltsverzeichnis

• Versionierte Modellerweiterung
• Sichere Promotion auf Primary
• Fehlerhafte Migration und Wiederanlauf
• Synchronisation eines Blueprint-Projekts
• Prüf- und Abnahmekriterien

Versionierte Modellerweiterung

Szenario: Ein Artikelmodell erhält ein neues validiertes Feld und einen wiederverwendbaren Block.

1. Schritt 1: Änderung und Abhängigkeiten beschreiben.
2. Schritt 2: Migration erzeugen und implementieren.
3. Schritt 3: Sandbox ausführen und Typen generieren.
4. Schritt 4: Redaktions- und Frontendtest protokollieren.

Prüfkriterium: Migration, generierte Typen, Redaktionsansicht und Frontendabfrage sind in der Sandbox geprüft und reproduzierbar.

Sichere Promotion auf Primary

Szenario: Mehrere Migrationen sind bereit, während im Primary noch redaktionelle Änderungen möglich sind.

1. Schritt 1: Releasefenster und Sperrverfahren vorbereiten.
2. Schritt 2: Aktuelle Sandbox erzeugen und Migrationen ausführen.
3. Schritt 3: Anwendungen gegen Sandbox testen.
4. Schritt 4: Promoten, Sperre aufheben und Nachkontrolle durchführen.

Prüfkriterium: Der Wechsel erfolgt aus einem aktuellen Ausgangszustand, ohne verlorene Änderungen, und besitzt einen klaren Rückfallpunkt.

Fehlerhafte Migration und Wiederanlauf

Szenario: Eine Migration bricht nach einer Teiloperation absichtlich ab.

1. Schritt 1: Teiloperation und Fehlerbedingung reproduzieren.
2. Schritt 2: Schema- und Migrationsstatus untersuchen.
3. Schritt 3: Idempotente Korrektur implementieren.
4. Schritt 4: Wiederanlauf und zweiten Kontrolllauf ausführen.

Prüfkriterium: Der Fehler ist diagnostiziert; ein erneuter Lauf erzeugt keinen inkonsistenten Zustand und die Korrektur ist versioniert.

Synchronisation eines Blueprint-Projekts

Szenario: Eine freigegebene Schemaänderung soll auf zwei abgeleitete Projekte übertragen werden.

1. Schritt 1: Zielprojekte und Ausgangsstände erfassen.
2. Schritt 2: Migrationen in getrennten Sandboxes ausführen.
3. Schritt 3: Abweichungen und Konflikte behandeln.
4. Schritt 4: Migrationsstände und Freigaben vergleichen.

Prüfkriterium: Beide Zielprojekte besitzen denselben Migrationsstand; projektspezifische Abweichungen sind erkannt und dokumentiert.

Prüf- und Abnahmekriterien

Die Übungen werden nicht allein nach sichtbarer Funktion, sondern nach Reproduzierbarkeit, Sicherheit, Datenqualität und Betriebsfähigkeit bewertet.

• Der Ausgangszustand, die Änderung und der geprüfte Zielzustand sind dokumentiert.
• Mindestens ein Negativ- oder Störungstest wurde kontrolliert durchgeführt.
• Geheimnisse, produktive Daten und unbeteiligte Systeme wurden nicht in die Übungen einbezogen.
• Offene Punkte besitzen Priorität, verantwortliche Stelle und nächsten Prüftermin.