Entwickeln und deployen (git-frei, dev-and-deploy)

Git-freie Dev-and-Deploy-Kette: Specs, Workspace- und Block-Release, Push, Pull aller Instanzen, Action install. Kanonischer Pfad /docs/polycrate/dev-and-deploy/.

Polycrate versioniert *.poly, führt Actions aus und installiert Pakete. Git ist kein Polycrate-Prozess. Ein vorhandenes Tag vX.Y.Z ist beim Finalize weder ein Fehler noch eine Warnung.

Diese Seite ist die kanonische Dev-and-Deploy-Kette. Details zu Workspaces, Blöcken und Actions bleiben auf den jeweiligen Seiten. Git-Workflows sind optional — siehe Git-Integration.

Sechs Schritte

  1. Specs auf done — Open Questions müssen leer sein (HTML-Kommentare zählen als leer).
  2. Workspace-SDD-Release — Family workspace, Ops release_create, release_update, release_finalize, release_status. Changelog-message und RELEASENOTE-Highlights sind beim Finalize Pflicht. Null zugewiesene Specs sind eine Warnung, kein Fehler.
  3. Release-pre_actions / post_actions laufen als vorgesehen mit Finalize.
  4. Block-SDD — Family block, Ops release_create, dann release_update (CHANGELOG-Message; app_version, wenn der Block ein App-Image trägt), dann release_finalize. Es gibt kein block bump.
  5. block Op push.
  6. Downstream: block Op pull mit einer Version schreibt from: auf jede Workspace-Instanz dieses FQBN (einmal unwrap). Danach action Op run mit Action install. Nicht image_tag schreiben oder als Produktcheck validieren.

CLI-Gegenstücke (kanonische Oberfläche):

polycrate spec update <id> --set status=done
polycrate release create X.Y.Z
polycrate release update X.Y.Z --set type=feat --set message="..."
polycrate release finalize X.Y.Z
polycrate block push <block>
polycrate block pull <registry/org/name:version>
polycrate run <block> install

--workspace / -w muss ein absoluter Pfad sein. Relatives -w ist ein Hard Fail.

MCP

Ein Server: polycrate mcp. Sechs Tools, keine Aliase, keine session_id. Bei mutierenden Ops einen absoluten workspace übergeben. Nie relatives -w.

  • sdd — list, inspect, create, update_meta, update_section, lint, format
  • docs — schema (lokal), guide (eingebettet), get/search (Backplane public; kein Scrape; kein Bearer)
  • hub — inspect_block, list_versions, list_blocks, info, cli_*
  • workspace — release_*
  • block — release_* plus push und pull (nicht package/consume)
  • action — run

sdd.update_section schreibt nur Sektionskörper (kein H1/H2/Frontmatter). Datei-Edit von Spec-Bodies bleibt erlaubt. Beides endet mit lint.

Das CLI-Manual (polycrate spec manual) ist optionale SSOT. Es gibt kein Pflicht-Ritual get_manual.

Mehr zur MCP-Integration: MCP Server.

Docker-Registry-Auth

Nicht ~/.docker/config.json mounten. Aus der Prozessumgebung in den Action-Container injizieren:

  • DOCKER_REGISTRY_HOST
  • DOCKER_REGISTRY_USER
  • DOCKER_REGISTRY_PASSWORD

CARGO_* ist nur Playbook-Fallback.

Hard Fail

Relatives -w, ungültige IDs, H1/H2 im Body von update_section, nicht-leere Open Questions bei sdd.update_meta status=done oder Workspace-Finalize zugewiesener Specs, leere Changelog-message, leere Highlights.

Kein Gate

Rotes spec verify, dirty Git, null Specs an einem Release, vorhandenes Git-Tag vX.Y.Z.

Was Polycrate nicht als Prozess verkauft

  • Git-Tag als Source of Truth
  • workspace sync als Release-Schritt
  • block bump
  • CI-first (CI konsumiert dieselbe Kette)
  • image_tag als Produktcheck

VCS bleibt euer Habit — nicht der Polycrate-Prozess. Siehe Git-Integration.

Weiter