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:
@@ -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.
|
||||
Reference in New Issue
Block a user