Skip to content
gStack

JHipster App Loop (dezvoltare per-aplicație, comună tuturor sistemelor GStack)

Scop: duci o aplicație GStack de la JDL + design la backend + frontend testat și livrat, uniform pentru toate subproiectele. Sursa procesului: docs/DEV-PLAYBOOK.md. Bucla de cod: run-until-green.

Precondiții (verifică ÎNTÂI — altfel oprește și pune în inbox batch)

Section titled “Precondiții (verifică ÎNTÂI — altfel oprește și pune în inbox batch)”
  • 03-development/<app>/<app>.jdl există (modelul = sursa de adevăr).
  • Caiet de sarcini Spec - <app> + design <app>.dc.html disponibile.
  • ADR-urile necesare au status Acceptat (vezi DEV-PLAYBOOK §4). ADR Propus → NU implementa.
  • config/.env are GitLab + chei model; proiectul govtech/gstack/<app> există (sau creează-l).

Pasul 1 — Scaffold / regenerare backend din JDL

Section titled “Pasul 1 — Scaffold / regenerare backend din JDL”

Convenții (aliniat cu glog, JHipster 9.1.0): microservice, oauth2/Keycloak, maven, PostgreSQL, Kafka, packageName systems.esempla.<app>, skipClient: true, limbi ro,ru,en.

Terminal window
cd 03-development/<app>
# model din JDL (idempotent; regenerabil la fiecare change request):
jhipster jdl <app>.jdl --skip-client --force

Reguli:

  • Nu edita manual entități/repos/DTO generabile din JDL — se pierd la regenerare.
  • Codul custom (servicii de business, integrări, mappers speciali) stă în clase/fișiere separate, marcate ca „needle” JHipster sau în pachete proprii, ca regenerarea să nu-l suprascrie.
  • Un change request de model = editează <app>.jdl întâi (spec-first, skill spec-first-change), apoi re-rulează jhipster jdl.

Pasul 2 — Frontend Angular din design

Section titled “Pasul 2 — Frontend Angular din design”
  • Sursa vizuală: <app>.dc.html (+ screenshots/). Extrage layout, componente, stări, culori.
  • Frontend separat. Rutare model: GLM pentru Angular.
  • Leagă la API-ul generat prin OpenAPI (/api/v1/openapi.json). Respectă zonele Standard API.
  • Frontendul e „done” doar cu teste (npm test) + (dacă există) Playwright pe backend pornit.

Pasul 3 — TDD + docker-compose (predă buclei run-until-green)

Section titled “Pasul 3 — TDD + docker-compose (predă buclei run-until-green)”

Pentru fiecare feature/task (2–5 min): RED → GREEN → REFACTOR prin skill run-until-green, care ridică docker-compose.test.yml (postgres+kafka+keycloak), rulează mvn -B verify + api_audit.py, apoi oprește mediul (down -v) chiar și la eșec. Vezi run-until-green §docker-compose.

Dacă docker-compose.test.yml lipsește pentru <app>, generează-l pornind de la serviciile din .yo-rc.json (postgres, kafka; keycloak dacă oauth2) și comite-l.

Pasul 4 — Scenarii de test documentate

Section titled “Pasul 4 — Scenarii de test documentate”

Actualizează 03-development/<app>/test-scenarios.md (ID TS-<app>-NN, precondiții, pași, rezultat așteptat, mapare CU-*/criteriu ↔ test automat). Oglindește pe wiki <app>/Scenarii-de-test. Reutilizează 02-specifications/_comune/biblioteca-cazuri-test-comune.md (TC-COM-*).

Pasul 5 — Review + livrare + checkpoint

Section titled “Pasul 5 — Review + livrare + checkpoint”
  • reviewer gate (spec + cod + Standard API). CRITICAL → înapoi la run-until-green.
  • gitlab-sync: issue actualizat, MR feat/<task-id> cu Closes #<issue> (nu push în main), wiki <app>/Stare + <app>/Arhitectura actualizate.
  • checkpoint-and-resume: task-ledger + state.json + checkpoint bogat. Apoi următorul task.

Definition of Done

Section titled “Definition of Done”

Vezi checklist-ul din docs/DEV-PLAYBOOK.md §10. Pe scurt: generat din JDL, front aliniat la design, unit+integrare verzi pe docker-compose, API audit trece, scenarii documentate, reviewer APPROVE, MR legat, checkpoint scris. „Done” înseamnă testat, dovedit — niciodată presupus.