6e458ae76f
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
5.5 KiB
5.5 KiB
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)
# 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
docker compose up -d
PlantUML-Rendering aktivieren
In data/gitea/conf/app.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):
[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
# .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:
settings:
digits: 3
prefix: REQ
.doorstop in jedem Requirements-Unterordner:
# reqs/sys/.doorstop
settings:
digits: 3
prefix: SYS
parent: null
# reqs/swe/.doorstop
settings:
digits: 3
prefix: SWE
parent: SYS
# 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.