CI/CD

Datenbank Migration

Wie läuft die Migration ab?

Die Migration erfolgt mit pg_upgrade – dem Standardwerkzeug für In-Place-Upgrades von PostgreSQL-Instanzen.

→ Offizielle Dokumentation zu pg_upgrade

Aufbau der Migration

Die Migration wird bei jeder Benutzeranmeldung ausgeführt. Dabei wird geprüft, ob neue .sql-Skripte in sql/Pg-upgrade2 oder sql/Pg-upgrade2-auth vorhanden sind, die noch nicht ausgeführt wurden. Bereits angewendete Migrationen werden in der Datenbanktabelle schema_info protokolliert, sodass sichergestellt ist, dass jedes Skript nur einmal ausgeführt wird.

Idempotente Skripte

Der Begriff idempotent stammt aus dem Lateinischen:
idem („gleich“) und potens („wirksam“).
Ein idempotentes Skript führt bei mehrfacher Ausführung stets zum selben Ergebnis. Das bedeutet, dass sich der Zustand der Instanz nach der ersten erfolgreichen Ausführung durch weitere Ausführungen nicht mehr ändert. Wiederholte Ausführungen haben somit keinen zusätzlichen Effekt.

Beispiel

Betrachten wir folgendes einfache PostgreSQL-Skript:

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL,
    email TEXT UNIQUE
);

CREATE INDEX idx_users_email ON users(email);

Wenn dieses Skript zweimal ausgeführt wird, tritt bei der zweiten Ausführung ein Fehler auf. Dies kann die Migration sowie das Update des ERP-Systems verlangsamen oder sogar vollständig verhindern.

Im Folgenden eine sichere, moderne und idempotente Alternative:

CREATE TABLE IF NOT EXISTS users (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL,
    email TEXT UNIQUE
);

CREATE INDEX IF NOT EXISTS idx_users_email ON users(email);

Vorteile von idempotenter Skripte

Idempotenz bietet den offensichtlichen Vorteil, dass ein Skript mehrfach ausgeführt werden kann, ohne dass sich das Ergebnis verändert. Zwar wirken idempotente Skripte oft komplexer, dennoch lohnt sich der Einsatz dieses Standards.

Weitere, weniger offensichtliche Vorteile sind:

  1. Sie sind ideal für komplexe CI/CD-Umgebungen, in denen Software auf mehreren SQL-Instanzen ausgeführt wird.

  2. Sie vereinfachen Automatisierung und Rollouts.

  3. Sie verhindern Duplikate und Fehler.

Obwohl unser ERP-System durch eine Protokollierung bereits gewährleistet, dass jedes Skript auf einer Datenbankinstanz nur einmal ausgeführt wird, ist Idempotenz in bestimmten Fällen besonders wichtig:

  1. Ein Kundenbranch enthält ein sehr ähnliches Migrationsskript.

  2. Die Einträge zur Durchführung eines Skripts gehen verloren.

  3. Zwei Migrationsskripte führen zum gleichen Ergebnis.

Code Reviews

⚠️ Dieser Prozess ist nicht final und kann sich jederzeit ändern oder weiterentwickeln.

Grundprinzipien

Ziele

Der Fokus liegt auf dem Gesamtbild, nicht auf Detailoptimierungen.

Im Review wird geprüft, ob:

Ziel ist es, schnell zu beurteilen, ob die Lösung insgesamt sinnvoll und wartbar ist.

Ablauf

Vorbereitung

Vor dem Erstellen eines Commits:

Review

Im Review wird vor allem geprüft:

Diskussionen konzentrieren sich auf:

Ergebnis

Ein Review gilt als nicht bestanden, wenn:

In diesem Fall sind Vereinfachung oder bessere Struktur erforderlich.

Präventive Code Reviews

Bei Unsicherheiten bezüglich Ansatz oder Design sollte frühzeitig Feedback eingeholt werden, bevor mit der Implementierung begonnen wird.

Best Practices

Autoren

Reviewer

Fazit

Code Reviews sind ein schneller, fokussierter Prozess zur Sicherstellung von verständlichem und gut integriertem Code.

CI/CD Pipeline – Übersicht

⚠️ Revision 2

Ziel

Diese Pipeline dient als automatischer Merge-Gate für das CE-Repository.
Sie stellt sicher, dass Änderungen vor dem Merge:

Zusätzlich reduziert sie Merge-Konflikte durch frühzeitige, kontinuierliche Integration.

Scope

Diese Version gilt für:

Die Pipeline läuft als Merged Results Pipeline.
Sie testet den Code so, wie er nach dem Merge aussehen würde.

Pipeline-Struktur

Die Pipeline besteht aus zwei Stages:

1. Validate

Schnelle Prüfungen:

Besonderheit:

Ziel: frühes, automatisiertes Feedback bei grundlegenden Problemen

2. Testing

Automatisierte Tests über t/test.pl mit PostgreSQL-Service.

Ziel: funktionale Korrektheit automatisch sicherstellen

Technische Details

Merge-Regeln

Ein Merge Request darf nur gemerged werden, wenn:

Workflow

  1. Branch erstellen (feature/*, improvement/*, fix/*, hotfix/*)
  2. Merge Request öffnen (frühzeitig)
  3. Pipeline läuft automatisch
  4. Fehler beheben bis Pipeline grün ist
  5. Code Review + QA
  6. Merge

Nicht Bestandteil (Revision 2)

Diese Themen sind aktuell nicht enthalten:

Zielwerte

Ausblick

Mögliche Erweiterungen in späteren Revisionen: