Software-Entwicklungslebenszyklus-Richtlinie

Letzte Aktualisierung: 25. März 2026

Verantwortlich: Rockxy Open-Source-Projekt

Zusammenfassung

Dieses Dokument beschreibt den Ansatz des Rockxy-Projekts zur Softwareentwicklung. Als Open-Source macOS-Entwicklertool halten wir uns an hohe Standards in Bezug auf Qualität, Sicherheit und Transparenz. Jede Codezeile ist öffentlich überprüfbar, und unser Entwicklungsprozess spiegelt diese Offenheit wider.

Anwendungsbereich

Diese Richtlinie gilt für alle Entwicklungsarbeiten innerhalb des Rockxy-Projekts, einschließlich der Hauptanwendung, Hilfstools, Build-Infrastruktur und dieser Website. Sie deckt den gesamten Lebenszyklus vom ersten Konzept bis zur laufenden Wartung ab.

Grundprinzipien

  • Qualität — Wir liefern Software, die zuverlässig, leistungsfähig und gut getestet ist. Jede Version durchläuft automatisierte und manuelle Qualitätssicherung, bevor sie die Nutzer erreicht.
  • Sicherheit — Sicherheit ist in jeder Phase verankert. Rockxy verarbeitet sensiblen Netzwerkverkehr, und wir nehmen diese Verantwortung ernst: keine Telemetrie, keine Datenerfassung und regelmäßige Abhängigkeitsprüfungen.
  • Transparenz — Der Quellcode ist öffentlich. Der Issue-Tracker ist öffentlich. Entscheidungen über Architektur, Prioritäten und Kompromisse werden offen dokumentiert.
  • Community — Beiträge aus der Community treiben Rockxy voran. Wir pflegen klare Beitragsrichtlinien, reaktionsschnelle Code-Reviews und eine inklusive Entwicklungsumgebung.

SDLC-Phasen

1. Ideenfindung und Scoping

Neue Funktionen und Verbesserungen werden über GitHub Issues und Community-Diskussionen vorgeschlagen. Wir bewerten Vorschläge nach Nutzerauswirkung, technischer Machbarkeit und Übereinstimmung mit der Projekt-Roadmap, bevor wir Ressourcen einsetzen.

2. Planung und Architektur

Akzeptierte Vorschläge gehen in eine Designphase, in der wir die Systemarchitektur definieren, Abhängigkeiten identifizieren, Risiken bewerten und Akzeptanzkriterien festlegen. Bei wesentlichen Änderungen schreiben wir Architecture Decision Records (ADRs) im Repository.

3. Entwicklung

Aller Code wird auf Feature-Branches entwickelt und über Pull Requests eingereicht. Jeder PR erfordert ein Code-Review vor dem Mergen. Wir folgen Swift- und SwiftUI-Konventionen, verwenden aussagekräftige Commit-Nachrichten und halten Änderungen fokussiert und überprüfbar.

4. Qualitätssicherung und Testen

Wir pflegen Unit-Tests, Integrationstests und manuelle QA-Checklisten. Sicherheitskritischer Code (TLS-Interception, Zertifikatsverwaltung, Proxy-Konfiguration) wird besonders gründlich geprüft. Wir testen auf allen unterstützten macOS-Versionen vor jeder Veröffentlichung.

5. Deployment und Release

Releases folgen der semantischen Versionierung. Jede Version enthält einen Changelog-Eintrag, einen signierten Build und die Verteilung über die offiziellen Kanäle des Projekts. Wir verwenden automatisierte Build-Pipelines, um reproduzierbare Builds sicherzustellen.

6. Wartung und Weiterentwicklung

Nach der Veröffentlichung beobachten wir Community-Feedback, priorisieren Fehlerberichte und liefern bei Bedarf Patches. Abhängigkeiten werden regelmäßig aktualisiert, und wir verfolgen Upstream-Sicherheitshinweise für alle Drittanbieter-Pakete.

Team- und Community-Dynamik

  • Kern-Maintainer — Verantwortlich für Architekturentscheidungen, Release-Management und die langfristige Projektausrichtung.
  • Mitwirkende — Community-Mitglieder, die Code, Dokumentation, Übersetzungen und Fehlerberichte einreichen. Alle Beiträge durchlaufen den Standard-PR-Review-Prozess.
  • Nutzer — Geben Feedback, melden Probleme und validieren Funktionen. Nutzereingaben beeinflussen direkt die Roadmap.

Dokumentation und Wissensaustausch

Wir pflegen Dokumentation auf mehreren Ebenen:

  • Inline-Code-Kommentare für nicht offensichtliche Implementierungsdetails
  • Architecture Decision Records für wesentliche Designentscheidungen
  • Nutzerdokumentation und Einrichtungsanleitungen
  • Beitragsrichtlinien und Coding-Standards im Repository
  • Engineering-Blogbeiträge mit technischen Vertiefungen

Compliance und Risikomanagement

Wir folgen branchenüblichen Best Practices für sichere Softwareentwicklung. Regelmäßige Abhängigkeitsprüfungen, Code-Signierung und Sandbox-Builds reduzieren Supply-Chain-Risiken. Rockxy erfasst keine Nutzerdaten, was die regulatorische Compliance vereinfacht. Sicherheitslücken können über unsere Sicherheitsrichtlinie gemeldet werden.

Kontinuierliche Verbesserung

  • Post-Release-Retrospektiven zur Identifizierung von Prozessverbesserungen
  • Regelmäßige Überprüfung von Tooling, Abhängigkeiten und Build-Infrastruktur
  • Community-Feedback wird in den Entwicklungsprozess integriert
  • Wissensaustausch durch Blogbeiträge und offene Diskussionen

Änderungen dieser Richtlinie

Aktualisierungen dieser Richtlinie werden im Rockxy-Quellrepository auf GitHub versioniert. Das Datum „Letzte Aktualisierung" oben zeigt die jüngste Überarbeitung an. Wesentliche Änderungen werden im Projekt-Changelog vermerkt.

Kontakt

Bei Fragen zu dieser Richtlinie oder unserem Entwicklungsprozess erstellen Sie bitte ein Issue auf GitHub.