59 lines
2.0 KiB
Markdown
59 lines
2.0 KiB
Markdown
# Utvecklingsprocess
|
|
|
|
Repositoryt är projektets facit. ChatGPT- eller Codex-dialoger kan användas som
|
|
arbetsyta, men implementation, tester och dokumentation ska tillsammans göra
|
|
projektets läge begripligt utan tidigare dialoger eller raderade branches.
|
|
|
|
## Arbetssätt
|
|
|
|
- Använd en kortlivad branch per feature eller annan avgränsad ändring.
|
|
- Skapa branchen från en uppdaterad `main`.
|
|
- En feature per ChatGPT-dialog är en praktisk arbetsform, inte en
|
|
dokumentationskälla.
|
|
- Skapa eller uppdatera feature-dokumentet inom samma feature.
|
|
- Ge Codex en tydligt avgränsad specifikation.
|
|
- Implementera endast uttryckliga krav och undvik spekulativ funktionalitet.
|
|
- Kör relevanta tester före commit och gör manuell verifiering när beteendet
|
|
motiverar det.
|
|
- Commit och push sker först efter uttrycklig instruktion.
|
|
- Merge sker först när ändringen har verifierats.
|
|
- Uppdatera arkitektur- och beslutsdokument när övergripande beslut förändras.
|
|
|
|
`main` ska innehålla verifierad kod. När en feature har mergats ska dess branch
|
|
kunna raderas utan att projektkunskap går förlorad.
|
|
|
|
## Rekommenderad featureprocess
|
|
|
|
1. Uppdatera `main`.
|
|
2. Skapa en avgränsad branch.
|
|
3. Skapa eller uppdatera feature-dokumentet.
|
|
4. Implementera specifikationen.
|
|
5. Kör relevanta automatiska tester och bygge.
|
|
6. Gör manuell verifiering där det är relevant.
|
|
7. Uppdatera dokumentationen så att den beskriver den faktiska lösningen.
|
|
8. Commit och push efter uttrycklig instruktion.
|
|
9. Merge efter verifiering.
|
|
10. Radera den mergade branchen.
|
|
|
|
## Verifiering före merge
|
|
|
|
För nuvarande projekt bör verifieringen normalt omfatta:
|
|
|
|
```bash
|
|
cd backend
|
|
./mvnw test
|
|
```
|
|
|
|
```bash
|
|
cd frontend
|
|
pnpm test
|
|
pnpm build
|
|
```
|
|
|
|
Kör även `git diff --check` och granska `git status --short`. Manuell lokal
|
|
verifiering av berörda flöden kompletterar, men ersätter inte, automatiska
|
|
tester.
|
|
|
|
Om ett befintligt test misslyckas av ett skäl utanför ändringens omfattning ska
|
|
det rapporteras; produktionskod ska inte ändras enbart för att dölja felet.
|