Eine Änderung ist nicht abgeschlossen, nur weil sie in einer Demonstration funktioniert, ein manueller Test das erwartete Ergebnis geliefert hat oder der Code den Hauptbranch erreicht hat. Diese Signale können einen Teil der Implementierung bestätigen, belegen jedoch nicht, dass die Änderung in der Produktion sicher, verständlich und betreibbar ist.
Die Definition of Done in PHP-Projekten muss festlegen, welche Nachweise eine konkrete Änderung akzeptabel machen. Sie muss das Geschäftsverhalten abdecken, aber auch bestehende Daten, asynchrone Aufgaben, Integrationen, Berechtigungen, Observability und die Rückabwicklung. So wird verhindert, dass das Produktteam etwas akzeptiert, das der Betrieb nicht dauerhaft tragen kann, oder dass die Technik eine Änderung bereitstellt, deren Auswirkungen schwer zu beheben sind.
Akzeptanz, Implementierung und Betrieb nicht verwechseln
Es ist sinnvoll, drei Zustände zu trennen, die häufig in einem einzigen „erledigt“ zusammengefasst werden:
- Akzeptierter Umfang: Es wurde überprüft, dass sich die vereinbarte Geschäftsregel in den relevanten Szenarien wie erwartet verhält.
- Abgeschlossene Implementierung: Code, Tests, Konfiguration und erforderliche Schemaänderungen sind vorbereitet und geprüft.
- Betreibbare Änderung: Sie kann bereitgestellt, überwacht und unterstützt sowie bei Bedarf eingeschränkt oder zurückgenommen werden, ohne das System in einem unbekannten Zustand zu hinterlassen.
In einer bestehenden PHP-Anwendung kann der Abstand zwischen diesen Zuständen erheblich sein. Eine neue Validierung in einem Controller kann eine Demonstration bestehen, aber eine Automatisierung blockieren, die dieselbe API verwendet. Eine Migration kann fehlerfrei ausgeführt werden und dennoch Werte transformieren, die ein Importprozess weiterhin mit der früheren Semantik interpretiert. Eine in der Benutzeroberfläche hinzugefügte Berechtigung wird möglicherweise nicht auf eine interne Route oder einen Konsolenbefehl angewendet.
Die Definition darf nicht zu einem einheitlichen Ritual werden. Sie muss dem Risiko angemessen sein: Eine isolierte visuelle Anpassung erfordert weniger Nachweise als eine Änderung bei Abrechnung, Berechtigungen, personenbezogenen Daten oder Abläufen mit externen Auswirkungen.
Eine Kriterienmatrix nach Auswirkungen erstellen
Klassifizieren Sie die Änderung vor der Entwicklung nach ihren Wirkungsflächen. Es ist nicht nötig, eine komplexe Punktzahl zu vergeben: Es genügt, zu ermitteln, welche Dimensionen sich ändern und welcher Fehler nicht akzeptabel wäre. Jede Dimension aktiviert zusätzliche Kriterien und Nachweise.
Geschäftslogik und Verhalten
Definieren Sie Regeln, Ausnahmen und Grenzzustände mit überprüfbaren Beispielen. Berücksichtigen Sie, was bei unvollständigen Daten, wiederholten Anfragen, Parallelität und vorhersehbaren Fehlern geschehen muss. Wenn eine Regel eine andere ersetzt, legen Sie fest, ab wann sie gilt und was mit Datensätzen geschieht, die nach der vorherigen Regel erstellt wurden.
Daten und Schema
Wenn Migrationen, neue Felder, die Neuberechnung von Informationen oder Importe vorliegen, bestimmen Sie das betroffene Volumen, die zeitliche Kompatibilität zwischen Anwendungs- und Schemaversionen sowie die nachträgliche Validierung. Eine abgeschlossene Migration bedeutet nicht, dass die Daten korrekt sind: Es müssen Anzahlen, ungültige Werte, Duplikate, unerwartete Nullwerte und der Erhalt relevanter Beziehungen überprüft werden.
Integrationen und asynchrone Prozesse
Queues, Cron, Webhooks, E-Mails, Dateispeicherung und externe APIs erfordern eigene Kriterien. Dokumentieren Sie Ein- und Ausgabeverträge, Wiederholungsversuche, Idempotenz, Timeouts, die Behandlung partieller Antworten und die Behandlung von Fehlern. In PHP kann ein Konsolenbefehl oder ein Worker andere Services und Zugangsdaten verwenden als eine Webanfrage; der Test muss diese realistische Ausführung abdecken.
Berechtigungen, Sicherheit und Datenschutz
Geben Sie an, wer jede Ressource sehen, erstellen, genehmigen, ändern oder exportieren darf. Die Autorisierung muss auf dem Server überprüft werden, nicht nur über die Sichtbarkeit einer Schaltfläche. Wenn personenbezogene Daten oder betriebliche Geheimnisse beteiligt sind, berücksichtigen Sie die Minimierung von Protokollen, Zugriffsbeschränkungen und die Überprüfung, welche Informationen in Fehlern, Traces und Benachrichtigungen erscheinen.
Betrieb und Bereitstellung
Legen Sie fest, wie ein Fehler nach der Bereitstellung erkannt wird: durch kontextreiche Protokolle, vorhandene Metriken, anwendbare Warnungen oder konkrete manuelle Prüfungen. Unterscheiden Sie Bereitstellung und Freigeben: Erstere installiert Artefakte und Konfiguration; Letzteres macht das Verhalten für Nutzer oder Prozesse verfügbar. Wenn möglich, kann eine Konfiguration, eine schrittweise Aktivierung oder eine Geschäftsbedingung die Exposition begrenzen, ohne dies mit einer vollständigen Rückabwicklung zu verwechseln.
Welche Nachweise die Änderung begleiten müssen
Eine Definition-of-Done-Liste ist nützlich, wenn sie beobachtbare Belege verlangt, nicht vage Formeln wie „validiert“ oder „dokumentiert“. Die Nachweise müssen von der Person, die die Änderung akzeptiert, überprüft werden können und während eines Incidents nutzbar sein.
- Automatisierte Tests: Unit-Tests für isolierte Regeln, Integrationstests für Persistenz, Autorisierungen und Services sowie End-to-End-Tests nur dort, wo sie tatsächlich Abdeckung für den Ablauf liefern.
- Akzeptanzprüfung: Ausgeführte Geschäftsszenarien mit identifizierten Eingaben, Ergebnissen und Rollen, einschließlich der Ablehnungsfälle.
- Migrationsergebnis: Ausführungsplan, Validierungen vor und nach der Migration, erwartete Anzahlen und explizite Behandlung von Anomalien.
- Integrationsvertrag: Änderungen an Feldern, Fehlercodes, Authentifizierung, Limits, Wiederholungsversuchen und Kompatibilität mit bestehenden Konsumenten.
- Betriebliche Überprüfung: Welches Protokoll, welche Metrik oder welche Abfrage bestätigt, dass der Ablauf nach der Bereitstellung funktioniert, und wer sie prüfen muss.
- Support-Leitfaden: Bekannte Symptome, zu suchende Kennungen, sichere Maßnahmen und Eskalation. Er muss kurz und zugänglich sein, keine allgemeine Dokumentation, die unter Druck nicht hilft.
Nicht jeder Nachweis muss ein eigenständiges Dokument sein. Ein Satz von Tests, eine Bereitstellungsnotiz und eine Validierungsabfrage können genügen, wenn sie präzise, auffindbar und zusammen mit der Änderung gepflegt werden.
Mindestkriterien und verstärkte Kriterien
Für eine Änderung mit geringem Risiko, ohne Änderung von Daten, externen Schnittstellen oder Berechtigungen, umfasst das Minimum üblicherweise akzeptierten Umfang, Code-Review, relevante Tests, identifizierte Konfiguration und eine Prüfung nach der Bereitstellung. Auch hier muss klar sein, was als korrektes Verhalten gilt.
Fügen Sie verstärkte Kontrollen hinzu, wenn eine der folgenden Bedingungen vorliegt:
- Persistente Daten werden erstellt, transformiert oder gelöscht.
- Eine Regel mit wirtschaftlichen, vertraglichen oder Compliance-Auswirkungen wird geändert.
- Rollen, Berechtigungen, Authentifizierung oder die Offenlegung von Informationen werden geändert.
- Auswirkungen werden an externe Systeme gesendet, etwa Zahlungen, E-Mails oder Webhooks.
- Die Änderung betrifft Worker, Queues, geplante Aufgaben oder Prozesse, die wiederholt ausgeführt werden können.
- Die Bereitstellung erfordert Abstimmung zwischen Anwendung, Datenbank, Infrastruktur oder Anbietern.
Berücksichtigen Sie in diesen Fällen Kompatibilität zwischen Versionen, einen geordneten Bereitstellungsplan, Datenvalidierungen, Tests vorhersehbarer Fehler, Observability, Entscheidungsverantwortliche und einen Eindämmungsplan. Die nützliche Frage lautet nicht „Gibt es Tests?“, sondern „Welcher Nachweis würde das spezifische Risiko dieser Änderung verringern?“.
Rückabwicklung: Kontrolle zurückgewinnen, nicht so tun, als wäre nichts passiert
Eine realistische Rückabwicklung hängt von den erzeugten Auswirkungen ab. Code zurückzunehmen kann einfach sein; eine destruktive Migration, eine gesendete E-Mail oder ein von einer externen API akzeptiertes Update rückgängig zu machen, ist es nicht. Deshalb muss das Kriterium zwischen der Rücknahme zukünftiger Ausführungen, der Kompensation bereits ausgelöster Auswirkungen und der Korrektur von Daten unterscheiden.
Definieren Sie vor dem Release den Schwellenwert, der ein Handeln erzwingen würde, wer die Entscheidung treffen darf und welche Maßnahmen sicher sind. Ein Konfigurations-Flag kann neue Ausführungen stoppen. Eine Queue kann pausiert werden, um weitere Auswirkungen zu verhindern. Eine kompensierende Korrektur kann eine menschliche Überprüfung erfordern, bevor bereits verarbeitete Datensätze geändert werden. Wenn es keine sichere automatische Rückabwicklung gibt, erklären Sie dies und bereiten Sie ein Wiederherstellungsverfahren mit klaren Grenzen vor.
Ein gültiger Rückabwicklungsplan identifiziert die irreversiblen Auswirkungen, die Art ihrer Eindämmung und die erforderlichen Nachweise, um zu erkennen, dass die Eindämmung funktioniert hat.
Beispiel: eine neue Genehmigung in einem PHP-Backoffice
Angenommen, ein Backoffice führt eine Regel ein: Bestimmte Anfragen müssen von einer spezifischen Rolle genehmigt werden, bevor sie zur Ausführung übergehen. Die Demonstration kann zeigen, dass eine Schaltfläche erscheint und sich der Status in „genehmigt“ ändert. Das reicht nicht aus.
Die Definition of Done muss das Zustandsmodell klären: Welche Anfragen benötigen eine Genehmigung, was mit bereits bestehenden geschieht, ob eine Genehmigung widerrufen werden kann und ob zwei Personen gleichzeitig handeln können. Es muss überprüft werden, dass der Domain-Service, die Controller, die API-Routen und die Konsolenbefehle dieselbe Autorisierung anwenden. Außerdem muss geprüft werden, dass ein Worker keine ausstehenden Anfragen ohne Genehmigung ausführt, weil er eine alte Abfrage verwendet.
Wenn ein Statusfeld hinzugefügt wird, benötigt die Migration eine Regel zur Klassifizierung historischer Datensätze und eine nachträgliche Prüfung der Anzahlen. Audit-Protokolle sollten gegebenenfalls Akteur, Zeitpunkt, Übergang und Grund aufbewahren, ohne unnötige sensible Informationen aufzunehmen. Der Betrieb muss wissen, wie sich in Erwartung einer Genehmigung feststeckende Anfragen erkennen lassen und wie die Verarbeitung gestoppt wird, wenn ein inkonsistenter Übergang auftritt. Die Rückabwicklung könnte die Anforderung für neue Anfragen deaktivieren, sollte jedoch bereits erfasste Genehmigungen nicht ohne eine ausdrückliche Entscheidung löschen.
Die Kriterien in den Delivery-Zyklus integrieren
Die Definition of Done darf nicht erst am Ende als Liste zum Abschließen einer Aufgabe formuliert werden. Während des Refinements identifizieren Produktteam und Technik Regeln, Abhängigkeiten, betroffene Daten und betriebliche Folgen. Vor der Entwicklung vereinbaren sie die Akzeptanzszenarien und erforderlichen Nachweise. Während der Implementierung leiten diese Nachweise Tests, Migrationen, Instrumentierung und Mindestdokumentation. Vor der Bereitstellung wird bestätigt, dass die Ausführungsreihenfolge, die Verantwortlichen und die Eindämmung weiterhin gültig sind.
Vermeiden Sie drei Anti-Patterns: allgemeine Listen, die das Risiko ignorieren; Kriterien, die erst entdeckt werden, wenn die Änderung bereits zur Bereitstellung bereit ist; und umfangreiche Dokumentation ohne umsetzbare Signale für den Support. Eine gute Definition of Done in PHP-Projekten fügt nicht standardmäßig Bürokratie hinzu. Sie macht explizit, was zutreffen muss, damit eine Änderung sicher betrieben werden kann, nachdem die Demonstration beendet ist.
