86 lines
5.5 KiB
Markdown
86 lines
5.5 KiB
Markdown
Hier ist dein maßgeschneidertes, ganzheitliches Konzept für deine All-in-One-Plattform. Wir nennen das Projekt in diesem Konzept vorläufig „DevSpace“ (du kannst den Namen natürlich jederzeit anpassen).
|
||
|
||
Dieses Dokument fasst all deine genialen Ideen, den logischen Aufbau und die Roadmap zusammen. Es dient dir ab jetzt als roter Faden für die Entwicklung mit Claude.
|
||
|
||
DevSpace Concept Paper: Das Next-Gen Developer OS
|
||
Die Vision: Weg von Atlassians zusammengeklebtem Werkzeugkasten, hin zu einer einzigen, nativen Plattform für den gesamten Software-Lebenszyklus. Keine Reibungsverluste, keine doppelten Logins, kein Chat-Chaos – alles aus einem Guss.
|
||
|
||
## 1. Die Core-Features (Der MVP)
|
||
Das ist das Fundament, das du als Erstes baust. Es ersetzt Jira und bietet durch die native Integration von Tag eins an einen massiven Mehrwert gegenüber Atlassian.
|
||
|
||
### 1.1 Das "Magic Dashboard" (Die Projekt-Zentrale)
|
||
Ein Projekt in DevSpace ist nicht nur ein Ticket-Board, sondern die Geburtsstätte eines Microservices oder einer Applikation.
|
||
|
||
- One-Click Provisioning: Beim Erstellen eines Projekts (z. B. PAY für Payment-Service) wird im Hintergrund vollautomatisch ein Gitea-Repository angelegt.
|
||
|
||
- Unified Status: Auf einen Blick sieht man den Zustand des Boards, die verknüpften Repos, aktive Sprints und den System-Status.
|
||
|
||
### 1.2 Hierarchisches Agile-Board (Das "Jira"-Herzstück)
|
||
Eine saubere, pfeilschnelle UI für Scrum-Teams, die die bewährte Hierarchie nutzt:
|
||
|
||
- Epics: Die großen Meilensteine (z. B. „PayPal-Integration“).
|
||
|
||
- Stories / Tasks / Bugs: Die konkreten Arbeitspakete (z. B. „PayPal Button in UI einbinden“).
|
||
|
||
- Subtasks: Die kleinteiligen technischen Schritte (z. B. „API-Payload validieren“).
|
||
|
||
- Status-Flow: Ein linearer, übersichtlicher Workflow: To Do ➔ In Progress ➔ Code Review (automatisch getriggert) ➔ Done.
|
||
|
||
### 1.3 Ressourcen- & Zeittracking (Die "Stunden-Bremse")
|
||
- Work-Logging: Entwickler loggen ihre Zeiten direkt im Ticket mit einem Klick.
|
||
|
||
- Mitarbeiter-Limits: Im Sprint-Planer wird für jeden Entwickler ein maximales Wochenstunden-Budget (z. B. 40h) hinterlegt. Das System warnt visuell bei Überplanung, bevor der Sprint gestartet wird.
|
||
|
||
### 1.4 Das "Living Ticket" (Dein Teams-Ersatz)
|
||
Schluss mit dem Hin-und-Her-Wechseln zwischen Jira und Teams/Mattermost.
|
||
|
||
- Nativer Ticket-Chat: Jedes Ticket hat ein eigenes Chat-Tab (Echtzeit via WebSockets). Wer dem Ticket zugewiesen ist, ist automatisch im Chat.
|
||
|
||
- Zentrale Chat-Inbox: Ein integrierter Messenger (wie Slack/Teams) zeigt dir links alle deine privaten Chats, Gruppen-Channels und eben deine aktiven "Ticket-Chats" an.
|
||
|
||
- Entscheidungs-Filter: Wichtige Chat-Nachrichten können als „Entscheidung“ markiert werden. Diese werden gefiltert in einer sauberen Timeline direkt im Ticket-Header angezeigt. Der Smalltalk bleibt im Chat, die harten Fakten stehen im Ticket.
|
||
|
||
## 2. Die Git-Integration (Die "Bitbucket"-Ader)
|
||
Wir erfinden das Rad nicht neu, sondern nutzen die Open-Source-Power von Gitea (oder Forgejo) als solide Engine im Hintergrund.
|
||
|
||
- Echtzeit-Synchronisation: Sobald ein Entwickler in Gitea einen Branch mit der Ticket-ID pusht (z. B. feature/PAY-12-paypal-button), passiert Folgendes:
|
||
|
||
- Das Ticket springt auf dem Board sofort auf In Progress.
|
||
|
||
- Im Ticket erscheint live ein Git-Widget mit dem Branch-Namen und den letzten Commits.
|
||
|
||
PR-Awareness: Wird ein Pull Request geöffnet, wechselt das Ticket auf In Code Review. Du siehst im Board-Ticket sofort:
|
||
|
||
- Wer Reviewer ist.
|
||
|
||
- Wie viele Kommentare im Code noch offen sind (z. B. "3 offene Diskussionen").
|
||
|
||
- Den direkten Link zum PR in Gitea.
|
||
|
||
## 3. Die Roadmap: Zukunfts-Pläne (Deine Erweiterungen)
|
||
Wenn das Core-System läuft, spinnst du das Netz Schritt für Schritt weiter, um die verbleibenden Atlassian- und DevOps-Lücken zu schließen.
|
||
```
|
||
Phase 1: Core (MVP) Phase 2: DevOps Phase 3: Ops & AI
|
||
+---------------------+ +---------------------+ +---------------------+
|
||
| - Scrum-Board | | - Integrierte | | - Live-Analytics |
|
||
| - Gitea-Engine | ➔ | Docker-Registry | ➔ | (Grafana-Style) |
|
||
| - Issue-Chat | | - Test-Management | | - Global Configs |
|
||
| - Zeittracking | | - Auto-Pipelines | | - Local AI (Ollama)|
|
||
+---------------------+ +---------------------+ +---------------------+
|
||
````
|
||
|
||
## Phase 2: Die DevOps-Erweiterung
|
||
- Integrierte Docker-Registry: Eine extrem performante, eigene Docker-Registry. Pipelines pushen direkt ohne Umwege dort hinein. Im Scrum-Ticket sieht man sofort: "Docker Image v1.2.0 erfolgreich gebaut" inklusive Direktlink zum Image-Protokoll.
|
||
|
||
- Natives Test-Management: Ein eigener Bereich für Qualitätssicherung. QA-Teams legen strukturierte Testfälle an. Schlägt ein automatisierter oder manueller Test fehl, wird direkt ein verknüpftes Bug-Ticket auf dem Board erstellt.
|
||
|
||
## Phase 3: Die Operations- & AI-Ebene
|
||
- Global Configuration Management: Ein Tool, um Config-Variablen festzulegen und über einen schlanken, serverseitigen Daemon (Go-Agent) live auf deine Server oder Docker-Container auszurollen.
|
||
|
||
- Native Analytics (Grafana-Style): Keine externen Dashboards mehr. Logs und Metriken werden direkt in DevSpace gestreamt. Wenn ein Server abstürzt, steht im Log direkt der klickbare Link zum Git-Commit, der den Fehler vermutlich verursacht hat.
|
||
|
||
- Local AI (Ollama): Ein datenschutzfreundlicher KI-Assistent, der lokal auf deiner Infrastruktur läuft. Er kann:
|
||
|
||
- Chatverläufe in Tickets zusammenfassen.
|
||
|
||
- Aus Fehlermeldungen in den Logs automatisch Bug-Tickets erstellen und den passenden Code-Abschnitt vorschlagen. |