Release

Versiuni

Versionare semantică (MAJOR.MINOR.PATCH) pentru întreaga platformă (aplicațiile și API-ul se livrează împreună, pentru că schema GraphQL e comună):

• PATCH — reparații fără schimbări de schemă sau de comportament vizibil.
• MINOR — funcționalități noi, compatibile (câmpuri noi, pagini noi, migrări care doar adaugă).
• MAJOR — schimbări care cer acțiuni (migrări care modifică date, schimbări de configurare obligatorii).

Ramuri

main e întotdeauna livrabil. Fiecare schimbare vine printr-un pull request cu testele ei; după aprobare și testele verzi intră în main. Release-urile sunt tag-uri vX.Y.Z pe main.

Lista de verificare înainte de release

1. Teste automate (toate trebuie să treacă):

   pnpm -r typecheck
   pnpm test:coverage                         # aplicațiile web: unitare + praguri de acoperire
   pnpm api:test && pnpm api:lint             # API: PHPUnit, stil, analiză statică
   pnpm test:e2e                              # cele 14 suite end-to-end, fiecare pe o bază proaspătă
   pnpm --filter @taraba/browser-tests test   # parcurs complet + accesibilitate

2. Migrări: fiecare migrare nouă a fost rulată pe o copie a datelor de producție; durata e cunoscută; migrările care șterg sau redenumesc coloane sunt împărțite în două release-uri (întâi codul nu mai folosește coloana, apoi migrarea o șterge).
3. Performanță: bugetele din specificații (măsurarea automată pe profilul volume se reia când scriptul e portat).
4. Documentație: pnpm docs:generate rulat, pnpm docs:build fără erori (verifică și linkurile rupte); ghidurile de utilizare actualizate pentru paginile schimbate.
5. Configurare: variabilele noi din .env.example sunt adăugate în mediul de producție.
6. Note de release: ce e nou pentru clienți, pentru echipă și pentru marketing; ce trebuie anunțat (de exemplu comisioane noi).

Pașii release-ului

1. Creează tag-ul: git tag v1.4.0 && git push --tags.
2. Copie de siguranță a bazei de date (vezi operarea).
3. Pe server: actualizează codul la tag și rulează

   docker compose build
   docker compose up -d db-setup        # aplică migrările (nu încarcă date demo în producție)
   docker compose up -d                 # înlocuiește containerele

   Pe cPanel: încarci deploy/out/api/ (fără .env și storage/) și rulezi php artisan migrate --force; vezi producția pe cPanel.
4. Verificare după release (10 minute):
   • GET /api/health → toate serviciile „up”;
   • conectare pe site cu un cont de test; căutare; pagina unui anunț;
   • conectare în Backoffice și CRM;
   • Panoul Backoffice fără cozi neobișnuite; jurnalul API fără erori;
   • pnpm db:check pe producție.
5. Anunță echipa (note de release) și închide release-ul.

Revenire (rollback)

• Fără migrări noi: repornește containerele la tag-ul anterior (docker compose up -d după checkout).
• Cu migrări: php artisan migrate:rollback --step=1 (în apps/api, sau docker compose run --rm api php artisan migrate:rollback --step=1) revine ultima migrare, doar dacă e reversibilă; altfel restaurează copia de siguranță făcută la pasul 2. De aceea migrările distructive sunt împărțite în două release-uri.
• După revenire: verificarea de la pasul 4 și o notă despre cauză.

Hotfix

Ramură din tag-ul în producție, reparația cu testul ei, același set de verificări, tag PATCH, apoi aceeași reparație în main.