Code zu erzeugen ist heute erstaunlich einfach. Eine Anforderung beschreiben, kurz warten, und schon liegen neue Komponenten, Datenbankmigrationen oder Tests im Arbeitsverzeichnis.
Das ist noch keine Lieferung.
Zwischen „Die KI hat etwas programmiert“ und „Diese Version kann verantwortet betrieben werden“ liegen Versionskontrolle, Review, Qualitätssicherung, Continuous Integration, Freigabe und verständliche Kommunikation. Fehlen diese Übergänge, wird Geschwindigkeit mit Fortschritt verwechselt.
Ein kontrollierter Software-Lebenszyklus macht jede Änderung nachvollziehbar: Woher kam sie? Was bewirkt sie? Wie wurde sie geprüft? Was wurde tatsächlich veröffentlicht? Und wie lässt sie sich zurücknehmen, wenn etwas schiefgeht?
Der Lebenszyklus beginnt vor dem Code
Eine Änderung sollte auf eine klare Anforderung oder einen nachvollziehbaren Fehler zurückgehen. Erst dann folgt die Umsetzung.
Der grundlegende Weg ist nicht kompliziert:
Anforderung → Änderung → Review → Prüfung → Freigabe → Release → Betrieb
In der Praxis gibt es Rücksprünge. Ein Test deckt eine unklare Anforderung auf. Ein Review zeigt ein Architekturproblem. Der Betrieb liefert Erkenntnisse, die eine neue Änderung auslösen. Genau deshalb ist der Software-Lebenszyklus kein Wasserfall mit hübschen Pfeilen, sondern ein geregelter Kreislauf.
KI kann jeden Schritt unterstützen. Sie sollte aber keinen davon unsichtbar überspringen.
Git speichert nicht nur Code, sondern Verantwortung
Versionskontrolle beantwortet drei einfache, aber wichtige Fragen:
- Was hat sich geändert?
- Warum wurde es geändert?
- Welcher Stand wurde geprüft und veröffentlicht?
Dafür müssen Commits klein und inhaltlich geschlossen bleiben. Wenn eine Änderung gleichzeitig eine Funktion ergänzt, Abhängigkeiten aktualisiert, Dokumentation umschreibt und nebenbei einen Fehler behebt, lässt sie sich schwer prüfen und noch schwerer gezielt zurücknehmen.
Ein guter Commit ist keine beliebige Momentaufnahme des Arbeitstages. Er bildet eine zusammenhängende Absicht ab.
Conventional Commits geben Änderungen eine Sprache
Conventional Commits definiert eine einfache Grundform:
<type>[optional scope][optional !]: <description>
Zum Beispiel:
fix(auth): abgelaufene Tokens zuverlässig ablehnen
Der Typ beschreibt die Absicht, der optionale Scope den betroffenen Bereich und ! eine inkompatible Änderung. Die Spezifikation legt insbesondere die Bedeutung von feat, fix und Breaking Changes fest. Weitere Typen sind zulässige Projektkonventionen. Sie werden nicht automatisch durch den Standard vorgeschrieben.
Eine praxistaugliche Typenliste kann so aussehen:
| Typ | Bedeutung |
|---|---|
feat | neue Funktion oder Fähigkeit |
fix | Fehlerbehebung |
docs | ausschließlich Dokumentation |
chore | allgemeine Wartung, für die kein präziserer Typ passt |
refactor | interne Umstrukturierung ohne neue Funktion oder Fehlerbehebung |
test | Tests hinzufügen, ändern oder korrigieren |
build | Build-System, Paketierung oder Build-Abhängigkeiten |
ci | Continuous-Integration- oder Deployment-Konfiguration |
perf | Leistungsverbesserung |
style | Formatierung ohne Verhaltensänderung; nicht visuelles UI-Design |
revert | eine frühere Änderung zurücknehmen |
Diese Struktur hilft Menschen beim Lesen der Historie. Maschinen können daraus Changelogs vorbereiten, Versionssprünge ableiten oder gezielte Prüfungen auslösen. Der Präfix ersetzt allerdings keine gute Beschreibung. fix: Fehler behoben bleibt auch formal korrekt ziemlich wertlos.
Tests sind keine Abschlussdekoration
Qualität entsteht nicht erst am Ende. Sie beginnt bei überprüfbaren Anforderungen, setzt sich in Architektur und Code fort und wird durch unterschiedliche Prüfungen sichtbar.
Welche Prüfungen nötig sind, hängt vom Risiko der Änderung ab:
- Formatierung und Linting erkennen mechanische Abweichungen.
- Typprüfungen finden widersprüchliche Daten- und Schnittstellenannahmen.
- Unit-Tests prüfen kleine, isolierte Einheiten.
- Integrations- und Vertragstests prüfen das Zusammenspiel von Komponenten und APIs.
- End-to-End-Tests prüfen reale Abläufe aus Nutzersicht.
- Barrierefreiheits-, Sicherheits- und Leistungstests decken wichtige Qualitätsmerkmale ab.
- Build- und Paketprüfungen zeigen, ob aus dem Quellstand tatsächlich ein auslieferbares Artefakt entsteht.
Nicht jede Änderung braucht jede Testart. Eine Textkorrektur erfordert andere Nachweise als eine neue Zahlungsfunktion. Die Auswahl muss proportional zum Risiko sein – und sie muss die tatsächlich veränderte Wirkung prüfen.
KI kann Tests entwerfen, Randfälle vorschlagen und Fehlerbilder analysieren. Sie neigt jedoch ebenso wie Menschen dazu, die eigene Implementierung zu bestätigen. Ein von derselben Aufgabenbeschreibung erzeugter Test kann dieselbe falsche Annahme enthalten wie der Code. Unabhängige Akzeptanzkriterien und Reviews bleiben deshalb wichtig.
Continuous Integration macht den Nachweis wiederholbar
Lokal erfolgreiche Tests sind ein Hinweis. Continuous Integration macht daraus einen reproduzierbaren Nachweis auf einem definierten Stand.
Bei jedem relevanten Commit oder Pull Request kann die CI beispielsweise:
- Abhängigkeiten reproduzierbar installieren,
- Formatierung, Linting und Typen prüfen,
- Unit-, Integrations- und Systemtests ausführen,
- Sicherheits- und Abhängigkeitsprüfungen starten,
- das auslieferbare Artefakt bauen,
- Prüfberichte und Abdeckung bereitstellen.
Ein grünes Symbol allein beweist allerdings wenig. Entscheidend ist, was geprüft wurde. Eine Pipeline kann erfolgreich sein und trotzdem keinen kritischen Nutzerablauf, keine Migration und keinen Wiederanlauf getestet haben.
Die CI ist deshalb kein magisches Qualitätssiegel. Sie ist die automatisierte Ausführung vereinbarter Kontrollen.
Commits, Changelog und Release Notes haben verschiedene Aufgaben
Die drei Ebenen werden häufig vermischt:
| Artefakt | Aufgabe | Hauptzielgruppe |
|---|---|---|
| Commit-Historie | technische Absichten einzelner Änderungen nachvollziehen | Entwicklung und Review |
| Changelog | wesentliche Änderungen über Versionen fortlaufend kuratieren | Nutzer, Betrieb und Entwicklung |
| Release Notes | eine konkrete Veröffentlichung mit Auswirkungen und Hinweisen erklären | Zielgruppe des jeweiligen Releases |
Ein Changelog nach Keep a Changelog und Semantic Versioning ist keine Kopie aller Commits. Release Notes wiederum sind kein automatisch erzeugter Textteppich. Sie erklären, was neu ist, welche Fehler behoben wurden, ob Breaking Changes vorliegen und welche Migrations- oder Betriebsmaßnahmen nötig sind.
KI kann aus strukturierten Commits und Pull Requests einen Entwurf erzeugen. Die Kuratierung bleibt notwendig: Nutzer interessieren sich für Auswirkungen, nicht für jede interne Dateiverschiebung.
Wo KI helfen darf – und wo nicht
Im Software-Lebenszyklus kann KI viel Routinearbeit übernehmen:
- Änderungen gegen Anforderungen und Projektregeln prüfen,
- Commits sinnvoll schneiden und Nachrichten vorschlagen,
- Tests und Randfälle ergänzen,
- CI-Fehler zusammenfassen,
- Changelog- und Release-Note-Entwürfe erstellen,
- betroffene Dokumentation und Betriebsanweisungen finden.
Sie sollte aber nicht stillschweigend Prüfungen deaktivieren, Produktionsänderungen freigeben oder einen fehlgeschlagenen Test als irrelevant erklären. Je höher die mögliche Auswirkung, desto klarer müssen Freigabe, Verantwortlichkeit und Rückbau sein.
Eine brauchbare Definition of Done
Eine Änderung ist nicht fertig, weil der Code vorhanden ist. Sie ist fertig, wenn mindestens diese Fragen beantwortet sind:
- Ist die zugrunde liegende Anforderung klar und erfüllt?
- Ist die Änderung klein, nachvollziehbar und reviewed?
- Sind die relevanten automatischen und manuellen Prüfungen erfolgreich?
- Wurde das tatsächliche auslieferbare Artefakt gebaut?
- Sind Migration, Konfiguration, Sicherheit und Rückbau berücksichtigt?
- Sind Changelog, Release Notes und Dokumentation passend aktualisiert?
- Ist eindeutig, welcher Stand freigegeben wurde?
- Kann der Betrieb erkennen, ob die Änderung gesund läuft?
Der letzte Punkt führt zum nächsten Abschnitt der Serie. Mit dem Deployment endet der Lebenszyklus nicht. Dann beginnt die Phase, in der Nutzer von der Software abhängen: ITSM und KI – Softwarebetrieb braucht Verantwortung.
