Entwicklungs und Arbeitsprozesse - Sawatec/streakify GitHub Wiki

Entwicklungs- und Arbeitsprozesse

Dieser Abschnitt beschreibt die Arbeitsprozesse und Entwicklungsabläufe in unserem Projekt, einschließlich der Branching-Strategie, des Merging-Prozesses, der Sprint-Planung und der Aufgabenverteilung.

Inhaltsverzeichnis

  1. Branching-Strategie
  2. Merging und Code-Review
  3. Sprint-Planung und Aufgabenverteilung
  4. Issue-Management und Labels

Branching-Strategie

Wir verwenden eine strukturierte Branching-Strategie, um die Entwicklung zu organisieren und die Zusammenarbeit im Team zu erleichtern.

  1. Main Branch (main)

    • Enthält die stabile, produktionsreife Version des Codes.
    • Nur getesteter und genehmigter Code wird in diesen Branch gemerged.

  2. Entwicklungs-Branch (develop)

    • Dieser Branch dient als Integrationszweig, in dem alle neuen Features zusammengeführt und getestet werden, bevor sie in den main Branch gelangen.

  3. Feature-Branches (feature/[feature-name])

    • Diese Branches sind für neue Features, die in Entwicklung sind.
    • Jeder Feature-Branch wird vom develop-Branch abgezweigt und nach Abschluss und Test dorthin zurückgeführt.

  4. Bugfix-Branches (bugfix/[bug-name])

    • Branches zur Behebung von Fehlern oder Problemen im Code.
    • Diese Branches werden vom develop-Branch abgezweigt und nach Abschluss dorthin zurückgeführt.

  5. Hotfix-Branches (hotfix/[issue-name])

    • Branches für kritische Fehlerbehebungen in der Produktionsumgebung.
    • Hotfixes werden direkt in den main-Branch gemerged und dann in develop synchronisiert.

Merging und Code-Review

  1. Code-Review

    • Jeder Merge-Request muss von mindestens einem Teammitglied überprüft werden.
    • Der Code wird auf Funktionalität, Lesbarkeit und Einhaltung der Standards geprüft.

  2. Merge-Richtlinien

    • Feature- und Bugfix-Branches werden nur nach erfolgreicher Prüfung und bestandenen Tests in develop gemerged.
    • Hotfixes werden direkt in den main-Branch gemerged und sofort deployed, falls erforderlich.

  3. Automatische Tests

    • Vor jedem Merge durchläuft der Code automatisierte Tests in der CI/CD-Pipeline.
    • Erst nach bestandenem Testlauf kann der Merge abgeschlossen werden.

Sprint-Planung und Aufgabenverteilung

  1. Sprint-Dauer

    • Jeder Sprint dauert drei Wochen und hat ein spezifisches Ziel, das am Ende erreicht sein soll.

  2. Sprint-Backlog

    • Das Team wählt aus dem Produkt-Backlog die User Stories und Aufgaben aus, die im aktuellen Sprint bearbeitet werden.
    • Das Sprint-Backlog wird in GitLab als Board visualisiert, um den Fortschritt zu verfolgen.

  3. Daily Stand-ups

    • Tägliche Meetings zur Abstimmung der Aufgaben, zum Austausch über Fortschritte und zum Beseitigen möglicher Blockaden.

  4. Sprint-Review und Retrospektive

    • Am Ende jedes Sprints werden die Ergebnisse überprüft und eine Retrospektive durchgeführt, um den Arbeitsprozess kontinuierlich zu verbessern.

Issue-Management und Labels

  1. Issue-Erstellung

    • Für jede User Story und jeden Task wird ein neues Issue in GitLab erstellt.
    • Die Issues werden entsprechend ihrer Priorität und ihres Status gekennzeichnet.

  2. Label-System

    • Priorität: High Priority, Medium Priority, Low Priority
    • Art der Aufgabe: Feature, Bug, Improvement, Documentation
    • Status: Open, In Progress, Review, Done
    • Bereich: Frontend, Backend, Database, DevOps

  3. Meilensteine und Aufgabenpakete

    • Jede größere Funktion oder Zielsetzung wird als Meilenstein markiert, um die Fortschritte zu verfolgen.
    • Kleinere Aufgaben werden als Child Issues angelegt und den Haupt-Issues zugeordnet.

Hinweis: Diese Prozesse werden kontinuierlich überprüft und angepasst, um eine effiziente und reibungslose Zusammenarbeit im Team zu gewährleisten.

Navigation

Alle Seiten

  1. Home
  2. Projektübersicht
  3. Anforderungen
  4. Technische Spezifikationen
  5. Setup und Installation
  6. CI/CD und Deployment
  7. Entwicklungs- und Arbeitsprozesse