Environments (dev → prod)

Warum Environments?

Ein Environment ist eine isolierte Ausprägung Ihres CMS-Inhalts – typischerweise dev zum Entwickeln und prod für die Live-Website. Struktur und Inhalte werden in dev gebaut und getestet und dann kontrolliert nach prod befördert.

Wichtig: Änderungen werden innerhalb des CMS zwischen Environments verschoben – nicht, indem man das Repository direkt gegen prod deployt.

Environments verwalten

# Vorhandene Environments auflisten
hcms env list
 
# Ein neues Environment aus einem bestehenden klonen
hcms env clone --from prod --to staging --name "Staging"

Beim Klonen wird immer das Schema übernommen; Inhalte, Seiten und Theme optional über --content, --pages (Seiten + Menüs) und --theme.

Änderungen befördern (promote)

hcms promote überträgt Änderungen in ein bestehendes Ziel-Environment:

hcms promote --from dev --to prod \
  --with-content --pages --menus --themes \
  --conflict overwrite --dry-run

Mit --conflict fail bricht der Vorgang ab, bevor der erste Schreibvorgang stattfindet. Den Status länger laufender Klon-/Promote-Vorgänge prüfen Sie mit hcms env status --op <id>.

Environment beim Deploy wählen

Fast jeder Struktur-Befehl akzeptiert --env, alternativ steuert das Feld environment in hcms.config.json das Standard-Ziel:

hcms schema push --env dev
hcms pages push --env dev

Tokens pro Environment trennen

• Entwickeln Sie gegen ein Token, das an das dev-Environment gebunden ist.
• Die Produktion nutzt ein separates Token, gebunden an prod, mit minimalem read-Scope (preview nur auf Vorschau-Deployments).
• Ist ein Token an ein Environment gebunden, wird ein abweichender ?environment=-Parameter in der Delivery-API ignoriert.

Regel: Richten Sie die lokale Entwicklung niemals auf das prod-Token. So bleibt die Live-Website vor versehentlichen Schreibzugriffen geschützt.