Skip to content

Architektonická rozhodnutí — Sentinel Ops

ADR-009: deploy.sh podpora single-env + non-git (official-image) služeb

  • Datum: 2026-06-18
  • Status: Přijato
  • Kontext: REQ-002 (Vaultwarden) je prod-only single-instance interní služba na oficiálním image (žádný build, žádný source git repo). deploy.sh ale (a) tvrdě vynucoval hub-before-prod gate (stamp + QA), který single-env služby nemůžou splnit, a (b) v fázi 1 dělal git pull origin + ve fázi 7.9 source/dist hash verifikaci, což non-git config projekt shodí.
  • Rozhodnutí: Dvě úzké úpravy deploy.sh:
  • Single-env detekce: když deploy.yml nemá domains.staging, prod deploy přeskočí hub-before-prod gate (hub/QA/deep stamp). Multi-env služby (mají staging) gate nadále plně platí.
  • Non-git / official-image: když projekt není git repo, fáze 1 přeskočí git pull (COMMIT=unknown); fáze 7.9 (commit + source/dist hash verifikace) se přeskočí pro COMMIT=unknown. Health check (fáze 7) zůstává jako primární ověření běhu.
  • Důsledky: Pipeline umí interní single-instance služby na oficiálních image (vaultwarden, vzor i pro budoucí n8n přes pipeline). Bezpečnostní gardy pro normální multi-env source služby beze změny (rozlišovač „chybí staging doména" / „není git" je bezpečný). Traceability single-env deploye je image-tag based, ne commit-hash.

ADR-008: Povinný DEPLOY.md — explicitní deklarace DB změn

  • Datum: 2026-03-29
  • Status: Přijato
  • Kontext: Auth deploy přidal sloupec available_scopes bez migrace → 500 na produkci. Agenti zapomínají deklarovat DB změny.
  • Rozhodnutí: Každý repo musí mít DEPLOY.md s povinným db_change fieldem (none/migration/manual-sql). Deploy.sh ho čte a bez něj odmítne nasadit. Při db_change=none cross-checkuje diff na migrační soubory. Agent dostane TODO s instrukcí co doplnit. Druhá úroveň: deploy request přes Relay musí taky obsahovat db_change.
  • Důsledky: Všechny repa potřebují DEPLOY.md. Agenti musí aktualizovat po každém releasu. Šablona v deploy/DEPLOY-TEMPLATE.md.

ADR-007: Pre-deploy snapshots s time-based rotací

  • Datum: 2026-03-26
  • Status: Přijato
  • Kontext: Pulse deploy smazal runtime YAML soubory (rsync --delete) a data z methodology_versions. Bez snapshotu nebyl rollback možný.
  • Rozhodnutí: Každý deploy vytvoří snapshot (app tar + DB dump + env) před rsync. Rotace: <24h keep all, 1-7d keep daily, 7-30d keep weekly, >30d delete. Rollback: ./deploy.sh <project> <env> --rollback [snapshot-id|latest]
  • Důsledky: Hub + prod potřebují psql pro DB dump. Cleanup cron na 02:00. ~2MB per snapshot (bez docker image). Při dnešních 5 deployích = 10MB, ne problém.

ADR-006: deploy.sh spouští migrace z deploy.yml

  • Datum: 2026-03-26
  • Status: Přijato
  • Kontext: Pulse migrace neproběhly na hub/prod. deploy.sh je nespouštěl, spoléhalo se na TypeORM synchronize (zakázáno). Hub musí být zrcadlo produkce.
  • Rozhodnutí: deploy.sh čte database.migration_command z deploy.yml a spouští po docker up, před health checkem. Pokud v deploy.yml chybí, migrace se přeskočí (chyba dev agenta).
  • Důsledky: Každý projekt s DB migracemi MUSÍ mít migration_command v deploy.yml. synchronize:true je zakázáno na všech prostředích.

ADR-001: Deploy přes deploy.sh, ne ruční příkazy

  • Datum: 2026-03-14
  • Status: Přijato
  • Kontext: Ruční deploye (rsync + docker compose) vedly k nekonzistencím — špatné porty, chybějící env vars, žádný rollback.
  • Rozhodnutí: Všechny deploye přes deploy/deploy.sh s deploy.yml manifestem. Žádný ruční rsync/scp.
  • Důsledky: Každý projekt musí mít deploy.yml. Deploy.sh zajišťuje: git pull, readiness check, rsync, docker build, health check, QA gate.

ADR-002: DO PG jako jediná databáze

  • Datum: 2026-03-18
  • Status: Přijato
  • Kontext: CS pipeline měl v .env.example lokální PG, což vedlo k záměně. Reálně všechny služby používají DO Managed PG.
  • Rozhodnutí: Všechny služby používají DO Managed PG. Žádné lokální PostgreSQL instance. .env.example soubory nejsou zdrojem pravdy.
  • Důsledky: DB mapping dokumentován v spec.md. Při jakémkoliv DB dotazu nejdřív konzultovat spec, pak /root/secrets/.

ADR-003: CORS whitelist v auth backendu musí obsahovat custom domény

  • Datum: 2026-03-18
  • Status: Přijato
  • Kontext: Auth backend CORS povoloval jen *.s60dev/hub/studio60.cz. Custom domény (billit.cz, pulselab.cz) byly blokovány → token exchange selhal.
  • Rozhodnutí: CORS whitelist musí obsahovat všechny custom domény. Ideálně načítat z DB (systems.home_url).
  • Důsledky: Při registraci nového systému s custom doménou → zkontrolovat CORS whitelist.

ADR-004: Auth entity změny MUSÍ mít migraci

  • Datum: 2026-03-18
  • Status: Přijato
  • Kontext: Auth agent přidal 3 sloupce (marketing_html, purchase_url, is_favorite) do entit bez migrací. Prod padal ~2h.
  • Rozhodnutí: Každá entity změna musí mít TypeORM migraci. Nikdy synchronize=true v produkci.
  • Důsledky: Deploy.sh by měl kontrolovat neprovedené migrace. QA gate musí testovat e2e login, ne jen health check.

ADR-005: Billit VITE build vars musí být v .env.prod

  • Datum: 2026-03-18
  • Status: Přijato
  • Kontext: Billit-web frontend se buildil bez VITE_AUTH_CLIENT_ID → fallback na dev defaults (auth.s60dev.cz). Prod redirectoval na neexistující stránku.
  • Rozhodnutí: VITE_AUTH_CLIENT_ID, VITE_AUTH_CLIENT_SECRET, VITE_AUTH_REDIRECT_URI, VITE_PUBLIC_URL musí být v /root/secrets/billit/.env.prod.
  • Důsledky: Deploy.sh readiness check kontroluje required vars z deploy.yml.