slohmaier/dev-process
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(i18n): toolstack.md + gitea-aspice-setup.md in English

Browse Source 
Last German files in the dev-process repo translated:
- toolstack/toolstack.md: tool overview, categories, descriptions
- gitea-aspice-setup.md: complete setup guide for Gitea + ASPICE

dev-process repo is now fully in English.
This commit is contained in:
Stefan Lohmaier
2026-05-12 03:43:36 -07:00
parent d5cfec9e42
commit 54e7decd9c
2 changed files with 181 additions and 181 deletions
Download Patch File Download Diff File Expand all files Collapse all files
gitea-aspice-setup.md
+77 -77
View File
@@ -1,10 +1,10 @@
# Gitea für ASPICE 4.0 einrichten
# Setting up Gitea for ASPICE 4.0
Konkrete Anleitung für den slohmaier Dev Process auf Basis von Gitea, Doorstop und Gitea Actions.
Concrete setup guide for the slohmaier Dev Process on top of Gitea, Doorstop, and Gitea Actions.
## Gitea installieren
## Install Gitea
### Docker (empfohlen)
### Docker (recommended)
```yaml
# docker-compose.yml
@@ -26,7 +26,7 @@ services:
docker compose up -d
```
### PlantUML-Rendering aktivieren
### Enable PlantUML rendering
In `data/gitea/conf/app.ini`:
@@ -39,7 +39,7 @@ RENDER_COMMAND = plantuml -tsvg -pipe
IS_INPUT_FILE = false
```
Oder über den öffentlichen Renderer (kein lokales PlantUML nötig):
Or via the public renderer (no local PlantUML needed):
```ini
[server]
@@ -51,85 +51,85 @@ NEED_POSTPROCESS = true
RENDER_COMMAND = curl -s https://www.plantuml.com/plantuml/svg/~h
```
## Organisations- und Repo-Struktur
## Organisation and repo structure
```
Organisation: slohmaier (eigene Projekte)
Organisation: kunde-projektname (Kundenprojekte)
Repo: projektname (Monorepo: reqs + docs + src + tests)
Organisation: slohmaier (own projects)
Organisation: client-projectname (customer projects)
Repo: projectname (monorepo: reqs + docs + src + tests)
```
Ein Repo pro Projekt. Kein Aufteilen in viele Repos.
One repo per project. Do not split into many repos.
## Label-Schema
## Label scheme
Alle Labels in der Organisation anlegen, dann in jedem Repo verfügbar.
Create all labels at the organisation level, then they are available in every repo.
| 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 |
| Label | Colour | Use |
|-------|--------|-----|
| `type:requirement` | blue | Requirement issue |
| `type:architecture` | dark blue | Architecture decision |
| `type:implementation` | green | Implementation task |
| `type:test` | light green | Test case |
| `type:document` | grey | Document change |
| `aspice:NC` | red | Non-conformity |
| `aspice:change-request` | orange | Change request |
| `aspice:finding` | yellow | QA finding |
| `status:review-required` | purple | Waiting for review |
| `status:approved` | green | Approved |
| `severity:critical` | dark red | Critical |
| `severity:major` | orange | Major |
| `severity:minor` | yellow | Minor |
## Branch-Schutz
## Branch protection
Für `main`:
- Kein direktes Pushen
- Mind. 1 Approval erforderlich
- CI muss grün sein
For `main`:
- No direct pushing
- At least 1 approval required
- CI must be green
Einstellbar unter: Repo → Settings → Branches → Branch Protection
Configurable under: Repo → Settings → Branches → Branch Protection
## Branching-Strategie
## Branching strategy
```
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
main protected, stable, only via PR
develop integration branch
feature/SWE-001-can-init feature with requirement reference
docs/qa-plan-v1 document change
fix/NC-003-misra-violation bug fix with NC reference
release/v1.0 release branch
```
## PR/Review-Workflow
## PR / review workflow
### Neue Anforderung anlegen
### Create a new requirement
```
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
2. Create file: reqs/swe/SWE-001.md
3. Create PR titled: "[REQ] SWE-001: CAN Bus Initialization"
4. Assign reviewer
5. After approval → merge
```
### Dokument ändern
### Change a document
```
1. Branch: docs/qa-plan-update
2. Änderung in docs/QA-Plan.md
3. PR mit Beschreibung der Änderung
4. Reviewer zuweisen → Approval → Merge
2. Change in docs/QA-Plan.md
3. PR with description of the change
4. Assign reviewer → approval → merge
```
### Code-Änderung
### Code change
```
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
2. Commit message: "feat(SWE-001): implement CAN bus init at configurable baudrate"
3. PR: "Refs #<issue-number>"
4. CI must be green
5. Reviewer → approval → merge
```
## Commit-Message-Konvention
## Commit-message convention
```
feat(SWE-001): implement CAN bus initialization
@@ -138,9 +138,9 @@ docs(QA-Plan): add review schedule for SWE phase
test(SWE-001): add unit test for CAN init error handling
```
Format: `<type>(<id>): <beschreibung>`
Format: `<type>(<id>): <description>`
## Gitea Actions — Basis-Pipeline
## Gitea Actions — basic pipeline
```yaml
# .gitea/workflows/validate.yml
@@ -183,9 +183,9 @@ jobs:
git push
```
## Doorstop konfigurieren
## Configure Doorstop
`.doorstop.yml` im Repo-Root:
`.doorstop.yml` at the repo root:
```yaml
settings:
@@ -193,7 +193,7 @@ settings:
prefix: REQ
```
`.doorstop` in jedem Requirements-Unterordner:
`.doorstop` in each requirements subfolder:
```yaml
# reqs/sys/.doorstop
@@ -219,24 +219,24 @@ settings:
parent: SWE
```
## VS Code Extensions für diesen Stack
## VS Code extensions for this 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 |
| Extension | ID | Purpose |
|--------------------|------------------------------|-------------------------------|
| PlantUML | jnbt.plantuml | Diagram preview in Markdown |
| Markdown All in One| yzhang.markdown-all-in-one | Markdown editing |
| YAML | redhat.vscode-yaml | YAML frontmatter in .md |
| GitLens | eamodio.gitlens | Git history and blame |
| Continue | Continue.continue | AI assistant, local via Ollama|
## Traceability-Übersicht
## Traceability overview
```
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)]
SYS-001 (system requirement)
└── SWE-001 (software requirement) [links: SYS-001]
└── TST-001 (test case) [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.
Doorstop verifies the complete chain automatically on every CI run.