Page tree
Skip to end of metadata
Go to start of metadata

Hier definieren wir erforderliche "Definition of Done" (DoD) Kriterien für einen PR, damit dieser für den Review und ggf. Merge zugelassen werden kann.


Brainstorming aus Paretz:


Allgemein/PRs

Neue PRs werden bei der Erstellung automatisch mit einem DoD Protokoll erstellt. Dieses muss vom PR-Ersteller abgearbeitet werden, bevor das WIP Label entfernt und damit der Review angefragt werden kann.

  • Links zu verwandten PRs anderer Repositories 
  • Link zum Ticket (URL vorbereitet)
    • Im Ticket (Oder im PR, wenn kein Ticket): Beschreibung (und Begründung) der Änderung/Neuerungen
  • Neuer PR ist automatisch mit dem Label WIP versehen
  • Review darf eröffnet werden, wenn alle DoD Punkte erfüllt sind. Review wird eingeleitet durch Zuweisen der Reviewer und Entfernen des WIP-Labels
    • Review Datenschutz → Release-Informationen bei Datenbankänderung oder Seed-Änderung (Datenschutzgruppe wird automatisch hinzugefügt)
  • Ein Mitglied der Gruppe "Review-..." muss den PR genehmigen, wird automatisch hinzugefügt

Tests

  • Keine Codecoverage Verringerung, Codecov verhindert Merge (Martin)
  • Bei neuen Features: Unit-Tests und Integrations-Tests schrieben (oder bei bestehenden, wenn keine Tests vorhanden)
  • Keine offenen bekannten Bugs im entwickelten Code

Dokumentation

  • Swagger (Server) - wenn API Änderungen vorgenommen wurden
  • Storybook (Client) - wenn neue UI Atome hinzugefügt wurden
  • Neue Abhängigkeiten (Repos, NPM Pakete, Vendor Skripte) begründen und überprüfen (Stabilität, Performance, Aktualität, Autor)
  • Übergabe/Schulung & Administrationsinfos (#Busfaktor, Confluence intern)
  • Gibt es wichtige User-Infos (Confluence öffentlich)
  • Müssen Guides/Hilfe aktualisiert werden?
  • Release Notes - wenn es sich um große Feature-Releases handelt
  • Changelog-Eintrag in der CHANGELOG.md des Projektes nach folgenden Regeln (siehe SOP: Changelog)

Datenschutz

  • Model-/Seedänderungen erfordern Review der Datenschutz-Gruppen (wird automatisch hinzugefügt)
  • Wenn personenbezogene Daten neu verarbeitet werden, muss das mit der Datenschutz-Gruppe besprochen werden

Code- und UI-Qualität

  • Keine Linter Probleme, Github prüft automatisch neuen Code auf Linter
  • Code immer mit Hinblick auf Security und Datensicherheit achten
  • Kernlogik im API programmiert?
  • Bei UI Änderungen: Review mit einer Frontend/UI/Design-Person durchgeführt?

Deployable

  • Feature Toggle notwendig?
  • Datenbankanpassungen notwendig? / Migrationsskripte
    • Alle DB-Anpassungen müssen in den Seed-Daten reflektiert werden
  • Neue Konfiguration an der Architektur/Hardware
  • Neue Berechtigungen/Rollen, Änderungen der Zugriffe auf Basis dieser




  • No labels