Seminar DatoCMS: Kompaktseminar von der Modellierung bis zum Go-live

Das Kompaktformat verbindet die wichtigsten DatoCMS-Entscheidungen in einem durchgehenden Pilotprojekt. In drei Tagen entstehen Zielbild, Content-Modell, redaktioneller Ablauf, GraphQL-Ausgabe, Frontendseite, Preview, Build- und Webhookpfad, Rollenmodell, Qualitätscheck und Go-live-Plan.

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.

• Ein begrenztes DatoCMS-Pilotprojekt fachlich und technisch strukturieren.
• Content-Modell, redaktionelle Pflege und Frontend-Ausgabe als Gesamtsystem umsetzen.
• Preview, Veröffentlichung, Rollen und Deploymentpfad praktisch verbinden.
• Go-live-Risiken mit Checklisten, Tests und Verantwortlichkeiten beherrschbar machen.

Typische Einsatzszenarien

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

• Projekt-Kick-off mit funktionsfähigem Prototyp.
• Technischer und redaktioneller Machbarkeitsnachweis.
• Gemeinsame Qualifizierung eines gemischten Einführungsteams.

Abgrenzung und Schwerpunkt

Die fachliche Tiefe wird durch folgende Grenzen bewusst fokussiert.

• Das Format verdichtet Inhalte und ersetzt keine tiefen Spezialseminare.
• Nur ein repräsentativer End-to-End-Prozess wird vollständig umgesetzt.
• Große Migrationen und individuelle Plugin-Entwicklung bleiben Folgeprojekte.

Vorbereitung und Arbeitsweise

Kapitelinhaltsverzeichnis

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

Zielgruppen

Interdisziplinäre Projektteams aus Product Ownership, Redaktion, UX, Entwicklung, Administration und Betrieb, die einen vollständigen Pilotablauf in kurzer Zeit benötigen.

Vorkenntnisse und Schulungsumgebung

Allgemeine Erfahrung mit Webprojekten. Für die technischen Übungen sind JavaScript- oder TypeScript-Grundkenntnisse im Team erforderlich; nicht jede teilnehmende Person muss programmieren.

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

• Pilotauftrag und Erfolgskriterien
• Content-Inventur und Zielmodell
• Redaktion, Medien und Structured Text
• GraphQL-Datenvertrag
• Frontendseite und Medienausgabe
• Draft, Preview und Veröffentlichung
• Rollen, Workflow und Verantwortungen
• Webhook, Build und Cache
• Go-live-Prüfung und Übergabe

Pilotauftrag und Erfolgskriterien

Der Pilot erhält einen klaren Umfang, messbare Abnahmekriterien und explizite Nicht-Ziele.

1. Schritt 1: Zielgruppen, Kanal und Pilotseite festlegen.
2. Schritt 2: Erfolgskriterien für Redaktion, Technik und Betrieb formulieren.
3. Schritt 3: Nicht-Ziele und offene Risiken dokumentieren.

Content-Inventur und Zielmodell

Aus realen Inhalten entsteht ein kleines, aber erweiterbares Modell mit Records, Beziehungen und Blocks.

1. Schritt 1: Beispielinhalte in fachliche Bausteine zerlegen.
2. Schritt 2: Modelle, Felder und Validierungen definieren.
3. Schritt 3: Schema mit repräsentativen Records und Grenzfällen testen.

Redaktion, Medien und Structured Text

Die Pflegeoberfläche wird mit Feldreihenfolge, Hilfetexten, Assets und modularen Inhalten redaktionstauglich gemacht.

1. Schritt 1: Redaktionellen Pflegeweg beschreiben.
2. Schritt 2: Medien und Structured-Text-Blocks konfigurieren.
3. Schritt 3: Record vollständig pflegen und Qualitätscheck durchführen.

GraphQL-Datenvertrag

Frontend und CMS werden über eine begrenzte, typisierte Query mit stabilen Fragmenten verbunden.

1. Schritt 1: Komponenten und benötigte Datenfelder festlegen.
2. Schritt 2: Query, Fragmente und Variablen erstellen.
3. Schritt 3: Nullfälle, Locales und Antwortgröße prüfen.

Frontendseite und Medienausgabe

Eine produktionsnahe Seite rendert Records, Blocks und responsive Medien.

1. Schritt 1: Route und serverseitigen Datenzugriff anlegen.
2. Schritt 2: Komponentenmapping für Blocks implementieren.
3. Schritt 3: Medien, Metadaten und Fehlerzustände testen.

Draft, Preview und Veröffentlichung

Entwürfe werden geschützt angezeigt und erst nach definierter Prüfung veröffentlicht.

1. Schritt 1: Preview-Einstieg und Entwurfszugriff konfigurieren.
2. Schritt 2: Änderung redaktionell prüfen und freigeben.
3. Schritt 3: Veröffentlichung und sichtbare Aktualisierung nachvollziehen.

Rollen, Workflow und Verantwortungen

Ein leichtgewichtiges Rollen- und Freigabemodell wird unmittelbar im Pilot erprobt.

1. Schritt 1: Autor, Freigabe, Entwicklung und Betrieb zuordnen.
2. Schritt 2: Zulässige Aktionen und Übergänge konfigurieren.
3. Schritt 3: Normalfall und abgelehnte Freigabe testen.

Webhook, Build und Cache

Inhaltsänderungen aktualisieren die Pilotanwendung kontrolliert und beobachtbar.

1. Schritt 1: Ereignis und betroffene Seiten bestimmen.
2. Schritt 2: Webhook oder Build-Trigger konfigurieren.
3. Schritt 3: Mehrfachereignis, Fehler und erneute Verarbeitung testen.

Go-live-Prüfung und Übergabe

Der Pilot wird anhand einer gemeinsamen Checkliste auf Inhalt, Sicherheit, Performance und Betrieb geprüft.

1. Schritt 1: Abnahmekriterien und offene Punkte zusammenführen.
2. Schritt 2: Smoke-Test, Rollenprüfung und Wiederherstellungsszenario durchführen.
3. Schritt 3: Owner, Betriebsroutine und nächste Ausbaustufe festlegen.

Praktische Übungen und Anwendung

Kapitelinhaltsverzeichnis

• End-to-End-Pilotseite
• Störung vor dem Go-live
• Go-live-Entscheidung
• Prüf- und Abnahmekriterien

End-to-End-Pilotseite

Szenario: Eine Kampagnen- oder Produktseite wird vom Modell bis zur sichtbaren Veröffentlichung umgesetzt.

1. Schritt 1: Pilotinhalt und Komponenten festlegen.
2. Schritt 2: Schema und Beispielrecords erstellen.
3. Schritt 3: Frontend und Preview implementieren.
4. Schritt 4: Freigeben, veröffentlichen und abnehmen.

Prüfkriterium: Modell, Record, Asset, Query, Frontend, Preview und Veröffentlichung funktionieren als zusammenhängender Prozess.

Störung vor dem Go-live

Szenario: Ein fehlerhafter Webhook und ein fehlendes Pflichtasset verhindern die erwartete Aktualisierung.

1. Schritt 1: Fehler reproduzieren und Zeitlinie erfassen.
2. Schritt 2: CMS-, Webhook- und Frontendstatus vergleichen.
3. Schritt 3: Ursachen beheben und Wiederanlauf durchführen.
4. Schritt 4: Präventionsmaßnahme in die Checkliste aufnehmen.

Prüfkriterium: Fehler werden getrennt diagnostiziert; Inhalt und Deployment werden kontrolliert korrigiert und erneut geprüft.

Go-live-Entscheidung

Szenario: Das Team bewertet den Pilot anhand fachlicher, technischer und betrieblicher Kriterien.

1. Schritt 1: Abnahmekriterien gewichten.
2. Schritt 2: Nachweise aus den Übungen zuordnen.
3. Schritt 3: Restpunkte nach Risiko priorisieren.
4. Schritt 4: Go-live oder Verschiebung mit Begründung dokumentieren.

Prüfkriterium: Eine nachvollziehbare Entscheidung mit Restpunkten, Ownern und Termin liegt vor.

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.