Initial commit: slohmaier Dev Process v1.0

ASPICE 4.0 / ISO 26262 Entwicklungsprozess fuer kleine Teams.

Inhalte:
- README mit hybrider Format-Strategie (Word + Markdown)
- Toolstack (Gitea, Doorstop, Cppcheck, gcov, CppUTest, pandoc)
- Markdown-Vorlagen fuer Requirements + Architektur (SA, SWA)
- Markdown-Vorlagen fuer formelle Dokumente (PID, PM-Plan, QA-Plan,
  SWE-Plan, Test-Plan, Reviews, Non-Conformity, MISRA Permits/Records)
- Word-Master-Template (slohmaier-doc-template.docx) mit ISO-9001-
  konformer Document Control, Formatvorlagen, Auto-Verzeichnissen
- Build-Scripts (build_word_template.py, generate_word_vorlagen.sh)
- gitea-aspice-setup.md, V-Modell-Infografik
This commit is contained in:
Stefan Lohmaier
2026-05-11 13:40:51 -07:00
commit 6e458ae76f
33 changed files with 2934 additions and 0 deletions
+242
View File
@@ -0,0 +1,242 @@
# Gitea für ASPICE 4.0 einrichten
Konkrete Anleitung für den slohmaier Dev Process auf Basis von Gitea, Doorstop und Gitea Actions.
## Gitea installieren
### Docker (empfohlen)
```yaml
# docker-compose.yml
version: "3"
services:
gitea:
image: gitea/gitea:latest
ports:
- "3000:3000"
- "222:22"
volumes:
- ./data:/data
environment:
- USER_UID=1000
- USER_GID=1000
```
```bash
docker compose up -d
```
### PlantUML-Rendering aktivieren
In `data/gitea/conf/app.ini`:
```ini
[markup.plantuml]
ENABLED = true
NEED_POSTPROCESS= true
FILE_EXTENSIONS = .puml
RENDER_COMMAND = plantuml -tsvg -pipe
IS_INPUT_FILE = false
```
Oder über den öffentlichen Renderer (kein lokales PlantUML nötig):
```ini
[server]
OFFLINE_MODE = false
[markup.plantuml]
ENABLED = true
NEED_POSTPROCESS = true
RENDER_COMMAND = curl -s https://www.plantuml.com/plantuml/svg/~h
```
## Organisations- und Repo-Struktur
```
Organisation: slohmaier (eigene Projekte)
Organisation: kunde-projektname (Kundenprojekte)
Repo: projektname (Monorepo: reqs + docs + src + tests)
```
Ein Repo pro Projekt. Kein Aufteilen in viele Repos.
## Label-Schema
Alle Labels in der Organisation anlegen, dann in jedem Repo verfügbar.
| Label | Farbe | Verwendung |
|-------|-------|------------|
| `type:requirement` | blau | Anforderungs-Issue |
| `type:architecture` | dunkelblau | Architektur-Entscheidung |
| `type:implementation` | grün | Implementierungsaufgabe |
| `type:test` | hellgrün | Testfall |
| `type:document` | grau | Dokument-Änderung |
| `aspice:NC` | rot | Non-Conformity |
| `aspice:change-request` | orange | Change Request |
| `aspice:finding` | gelb | QA-Finding |
| `status:review-required` | lila | Wartet auf Review |
| `status:approved` | grün | Freigegeben |
| `severity:critical` | dunkelrot | Kritisch |
| `severity:major` | orange | Schwerwiegend |
| `severity:minor` | gelb | Geringfügig |
## Branch-Schutz
Für `main`:
- Kein direktes Pushen
- Mind. 1 Approval erforderlich
- CI muss grün sein
Einstellbar unter: Repo → Settings → Branches → Branch Protection
## Branching-Strategie
```
main protected, stabil, nur via PR
develop Integrationsbranch
feature/SWE-001-can-init Feature mit Req-Referenz
docs/qa-plan-v1 Dokument-Änderung
fix/NC-003-misra-violation Bugfix mit NC-Referenz
release/v1.0 Release-Branch
```
## PR/Review-Workflow
### Neue Anforderung anlegen
```
1. Branch: reqs/SWE-001-can-init
2. Datei anlegen: reqs/swe/SWE-001.md
3. PR erstellen mit Titel: "[REQ] SWE-001: CAN Bus Initialisierung"
4. Reviewer zuweisen
5. Nach Approval → Merge
```
### Dokument ändern
```
1. Branch: docs/qa-plan-update
2. Änderung in docs/QA-Plan.md
3. PR mit Beschreibung der Änderung
4. Reviewer zuweisen → Approval → Merge
```
### Code-Änderung
```
1. Branch: feature/SWE-001-can-init
2. Commit-Message: "feat(SWE-001): implement CAN bus init at configurable baudrate"
3. PR: "Refs #<issue-nummer>"
4. CI muss grün sein
5. Reviewer → Approval → Merge
```
## Commit-Message-Konvention
```
feat(SWE-001): implement CAN bus initialization
fix(NC-003): resolve MISRA Rule 14.4 violation
docs(QA-Plan): add review schedule for SWE phase
test(SWE-001): add unit test for CAN init error handling
```
Format: `<type>(<id>): <beschreibung>`
## Gitea Actions — Basis-Pipeline
```yaml
# .gitea/workflows/validate.yml
name: Validate
on: [push, pull_request]
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Install tools
run: |
pip install doorstop
apt-get install -y cppcheck
- name: Doorstop check
run: doorstop check
- name: MISRA check
run: |
cppcheck --addon=misra --error-exitcode=1 \
--suppress=misra-c2012-15.5 \
src/
- name: Unit tests
run: make test
- name: Coverage
run: make coverage
- name: Publish traceability
run: |
doorstop publish all docs/traceability/
git config user.email "ci@slohmaier.com"
git config user.name "CI"
git add docs/traceability/
git diff --cached --quiet || git commit -m "ci: update traceability report"
git push
```
## Doorstop konfigurieren
`.doorstop.yml` im Repo-Root:
```yaml
settings:
digits: 3
prefix: REQ
```
`.doorstop` in jedem Requirements-Unterordner:
```yaml
# reqs/sys/.doorstop
settings:
digits: 3
prefix: SYS
parent: null
```
```yaml
# reqs/swe/.doorstop
settings:
digits: 3
prefix: SWE
parent: SYS
```
```yaml
# tests/unit/.doorstop
settings:
digits: 3
prefix: TST
parent: SWE
```
## VS Code Extensions für diesen Stack
| Extension | ID | Zweck |
|-----------|-----|-------|
| PlantUML | jnbt.plantuml | Diagramm-Preview in Markdown |
| Markdown All in One | yzhang.markdown-all-in-one | Markdown-Bearbeitung |
| YAML | redhat.vscode-yaml | YAML-Frontmatter in .md |
| GitLens | eamodio.gitlens | Git-History und Blame |
| Continue | Continue.continue | KI-Assistent lokal via Ollama |
## Traceability-Übersicht
```
SYS-001 (System-Anforderung)
└── SWE-001 (Software-Anforderung) [links: SYS-001]
└── TST-001 (Testfall) [links: SWE-001]
└── Commit abc1234 [feat(SWE-001): ...]
└── PR #12 [Refs #5 (Issue: SWE-001)]
```
Doorstop prüft die komplette Kette automatisch bei jedem CI-Lauf.