Wahl Ihrer Deployment-Methode

docmd bietet vier Wege, Ihre Dokumentation live zu schalten. Sie alle erzeugen dieselbe Ausgabe — eine statische Site, bereitgestellt auf GitHub Pages oder einem Hosting-Provider Ihrer Wahl — unterscheiden sich aber darin, wie viel Kontrolle Sie wünschen und wo Sie starten.

Schnelle Entscheidungsmatrix

Szenario-Leitfaden

“Ich will Docs in unter zwei Minuten live, ohne Setup”

Verwenden Sie die GitHub App. Installieren, Repository wählen, fertig. Sie erkennt Ihre Konfiguration, generiert den Workflow, aktiviert GitHub Pages und stellt bereit — ohne dass Sie eine einzige Datei anfassen.

“Ich starte eine brandneue Dokumentations-Site”

Verwenden Sie das Starter-Template. Klicken Sie auf GitHub auf “Use this template”, aktualisieren Sie docmd.config.json mit Ihrem Titel und Ihrer URL, aktivieren Sie GitHub Pages einmalig und pushen Sie. Alles ist vorverkabelt.

“Ich habe eine bestehende CI/CD-Pipeline und möchte Docs hinzufügen”

Verwenden Sie die GitHub Action. Fügen Sie docmd-io/deploy@v1 in Ihren bestehenden Workflow ein. Sie komponiert sich sauber mit anderen Schritten — Tests laufen lassen, Ihre App bauen, dann Docs bauen, alles in einem Job.

“Ich deploye zu Vercel, Netlify, Docker oder meinem eigenen Server”

Verwenden Sie das Deployer-Paket. Führen Sie npx @docmd/core deploy --vercel (oder --netlify, --docker, --nginx) aus, um anbieterspezifische Konfigurationsdateien zu generieren, die auf Ihre docmd.config.json zugeschnitten sind.

“Ich bin in einem Monorepo mit Docs in einem Unterverzeichnis”

Sowohl die GitHub App als auch das Deployer-Paket handhaben dies automatisch. Die App erkennt Konfigurationen überall im Repository-Baum und fügt das korrekte --cwd-Flag ein. Das Deployer-Paket liest Ihre Konfiguration aus dem aktuellen Arbeitsverzeichnis.

Bevorzugen Sie die GitHub Action, übergeben Sie --cwd manuell:

- run: npx @docmd/core build --cwd packages/docs

“Ich möchte Docs bei jedem Pull Request in der Vorschau sehen”

Verwenden Sie die GitHub Action in Kombination mit einem PR-Preview-Service (z. B. Cloudflare Pages Preview-Deployments oder einer selbstgehosteten Preview-Umgebung). Eine vollständige Anleitung finden Sie unter Änderungen in der Vorschau anzeigen.

Wie sie zusammenpassen

Diese Methoden schließen sich nicht gegenseitig aus. Eine häufige Entwicklung sieht so aus:

Start mit der GitHub App (schnellster Weg ins Live)
  ↓
Generierte Workflow-Datei anpassen, wenn die Anforderungen wachsen
  ↓
Deployer-Paket hinzufügen, um Nginx/Docker-Konfigurationen für Self-Hosting zu generieren
  ↓
Action in eine umfassendere CI/CD-Pipeline integrieren

Sie können sie auch mischen: Verwenden Sie das Starter-Template für ein neues Projekt und fügen Sie später das Deployer-Paket hinzu, um ein Docker-Image für Ihre Staging-Umgebung zu generieren.

Build-Trigger im Vergleich

Weiterführende Lektüre

• GitHub-Action-Referenz
• GitHub-App-Referenz
• Starter-Template-Referenz
• Deployer-Paket-Referenz
• GitHub-Actions-CI/CD-Leitfaden
• Änderungen in der Vorschau anzeigen