Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
94 lines (68 loc) · 3.16 KB

CONTRIBUTING.md

File metadata and controls

94 lines (68 loc) · 3.16 KB
Raw

Contributing to ApplicationOps

Danke, dass du zu ApplicationOps beitragen möchtest! 🎉

Lizenz

Durch das Einreichen eines Pull Requests stimmst du zu, dass dein Code unter denselben Bedingungen wie das Projekt lizenziert wird (GNU AGPL v3.0).

Wenn du als Unternehmen beitragen möchtest, ohne die AGPL-Pflichten zu übernehmen, kontaktiere uns für eine Contributor License Agreement (CLA): licensing@bentech.app

Wie du beitragen kannst

1. Issue erstellen

  • Bug Report: Beschreibe das Problem, Schritte zur Reproduktion, erwartetes vs. tatsächliches Verhalten
  • Feature Request: Beschreibe den Use Case, nicht die Implementierung
  • Frage: Nutze GitHub Discussions (nicht Issues)

2. Entwicklungsumgebung einrichten

# Voraussetzungen
# - Java 21+
# - Docker & Docker Compose
# - Mistral API Key

# Repository klonen
git clone https://github.com/bentechapp/application-ops.git
cd application-ops

# Infrastruktur starten
docker compose up -d postgres nats redis minio

# Environment
export MISTRAL_API_KEY="your-key"
export DB_PASSWORD="appops"

# Bauen & Starten
./mvnw -pl application-ops-api spring-boot:run

3. Branch-Strategie

main         ← Produktionscode (nur via PR)
├── feat/*   ← Neue Features
├── fix/*    ← Bugfixes
└── docs/*   ← Dokumentation

4. Code-Stil

  • Java 21 mit Spring Boot 4.0.6
  • DDD-Schichttrennung: API → Core (nie umgekehrt). ArchUnit-Tests prüfen das.
  • Copyright-Header: Jede neue Datei muss den Standard-Header tragen: 
    // ApplicationOps Engine — Semantic Supply-Demand Matching Platform
// Copyright (c) 2026 Skander Ben Abdelmalak | bentech.app
// Lizenziert unter AGPLv3. Kommerzielle Lizenzierung: licensing@bentech.app
  • Keine Enterprise Readiness Marker: Wenn Code fertig ist, kein Kommentar nötig. Nur TODOs für unfertige Stellen.
  • Tests: Neue Features brauchen Tests. Integration-Tests bevorzugt (Testcontainers + PostgreSQL).

5. Pull Request

  1. Branch von main erstellen
  2. Änderungen mit Tests implementieren
  3. ./mvnw verify muss grün sein
  4. PR erstellen mit:
    • Was wurde geändert?
    • Warum?
    • Wie wurde getestet?

6. Review-Prozess

  • Maintainer reviewt innerhalb von 3 Werktagen
  • Änderungen werden angefragt via PR-Kommentare
  • Nach Approval wird in main gemerged

Architektur-Richtlinien

Lies die arc42-Dokumentation und die ADR-Entscheidungen bevor du größere Änderungen vornimmst.

Kernprinzipien:

  1. Domain-Driven Design: Business-Logik in application-ops-core, niemals in Controllern
  2. Evidence-Based: Architekturentscheidungen brauchen Begründung (Paper, Messung, Benchmark)
  3. Graceful Degradation: Jede externe Abhängigkeit braucht einen Fallback
  4. Keine Hardcoded Secrets: Environment Variables oder Spring Cloud Config

Kontakt