Die PHP-Version einer bestehenden Anwendung zu aktualisieren, bedeutet nicht einfach, das Container-Image oder die Serverkonfiguration zu ändern. Die Laufzeitumgebung interagiert mit dem Code, den Erweiterungen, den Composer-Bibliotheken und den Prozessen, die geplante Aufgaben oder Hintergrundjobs ausführen. Eine Änderung kann sich auf jedes dieser Elemente auswirken, selbst wenn die Anwendung bei einem manuellen Test scheinbar normal funktioniert.
Unsicherheit lässt sich verringern, indem das Update als Kompatibilitätsänderung behandelt wird: Erfassen Sie, was ausgeführt wird, suchen Sie nach Inkompatibilitäten, validieren Sie repräsentative Abläufe und legen Sie im Voraus fest, anhand welcher Kriterien entschieden wird, ob die Bereitstellung fortgesetzt oder zurückgenommen wird. Ziel ist es, den für die neue Laufzeitumgebung notwendigen Arbeitsumfang einzugrenzen und das Update nicht in eine Neuentwicklung des Produkts zu verwandeln.
Die Laufzeitumgebung ist Teil der Anwendungskompatibilität
Die PHP-Version bestimmt, welche Syntax der Interpreter unterstützt und wie sich bestimmte Funktionen und Typen verhalten. Außerdem legt sie fest, welche Versionen von Erweiterungen und Abhängigkeiten installiert werden können. Dass der Code in der aktuellen Umgebung funktioniert hat, beweist deshalb nicht, dass er auch in der neuen funktioniert: Eine Funktion, eine Schnittstelle, das Verhalten von Typen oder die Verfügbarkeit einer Erweiterung könnten sich ändern.
Es empfiehlt sich, drei Bereiche zu unterscheiden: den Anwendungscode, Abhängigkeiten von Drittanbietern und die Umgebungskonfiguration. Werden alle drei gleichzeitig geändert, lässt sich ein Fehler schwerer zuordnen. Bei einem geplanten Update werden diese Änderungen, soweit praktikabel, voneinander getrennt und es bleibt nachvollziehbar, welche Komponente die jeweilige Anpassung erforderlich gemacht hat.
Laufzeitumgebung, Abhängigkeiten und Prozesse erfassen
Erfassen Sie vor jeder Änderung die tatsächliche Laufzeitumgebung und nicht nur diejenige, die in der Projektkonfigurationsdatei beschrieben ist. Prüfen Sie die PHP-Version in den Containern oder Servern, die Anfragen bearbeiten, sowie in den Umgebungen, in denen geplante Aufgaben, Queue-Worker und Wartungsbefehle ausgeführt werden. Diese Prozesse können andere Images, Variablen oder Erweiterungen verwenden.
- Laufzeitumgebung und Erweiterungen: Ermitteln Sie die aktivierten Erweiterungen, gegebenenfalls ihre Versionen und die Systembibliotheken, von denen sie abhängen. Vergleichen Sie die Anforderungen von Produktion, CI und Entwicklung.
- Composer-Abhängigkeiten: Prüfen Sie
composer.json, die Lock-Datei und die von den Paketen deklarierten PHP-Anforderungen. Berücksichtigen Sie auch Entwicklungstools wie Analyzer und Test-Runner. - Konfiguration: Erfassen Sie die Werte in
php.ini, Speicher- und Zeitlimits, die Fehlerkonfiguration und serverspezifische Einstellungen. Eine neue Laufzeitumgebung garantiert nicht, dass relevante Parameter beibehalten wurden. - Arbeiten außerhalb von Webanfragen: Berücksichtigen Sie cron, Queues, Konsolenbefehle, Importe, Exporte und lang laufende Aufgaben. Ein funktionierender Webpfad validiert diese Abläufe nicht automatisch.
- Integrationen und Daten: Notieren Sie externe Dienste, ausgetauschte Formate sowie Schreibvorgänge in Datenbanken oder Speicher. So lässt sich erkennen, welche Vorgänge bei einem Rollback besondere Aufmerksamkeit erfordern.
Das Inventar kann als Liste im Repository oder in der Betriebsdokumentation gepflegt werden, sofern es den Vergleich der Umgebungen und das Erkennen von Abweichungen ermöglicht. Ein häufiges Anzeichen für ein unvollständiges Inventar ist, dass CI erfolgreich ist, aber nach der Bereitstellung ein Worker oder eine geplante Aufgabe ausfällt.
Inkompatibilitäten anhand mehrerer Signale suchen
Beginnen Sie mit automatisierten Tools: Prüfen Sie die Plattformanforderungen von Composer und führen Sie mit der vorgesehenen PHP-Version eine Abhängigkeitsprüfung durch. Ein Auflösungskonflikt weist darauf hin, dass ein Paket – einschließlich der Entwicklungstools – keine Kompatibilität mit dieser Plattform deklariert. Erzwingen Sie die Installation nicht, um den Konflikt zu verbergen, ohne zu verstehen, welche Anforderung dadurch umgangen wird.
Ergänzen Sie diese Analyse mit statischen Analysewerkzeugen und den im Projekt verfügbaren Tools für Stil- oder Kompatibilitätsprüfungen. Sie können auf verdächtige Verwendungen, veraltete APIs oder überprüfungsbedürftige Muster hinweisen, beweisen aber nicht allein, dass die gesamte Anwendung funktioniert. Ebenso ersetzt eine Analyse ohne Befunde nicht die tatsächliche Ausführung: Manche Fehler treten erst auf, wenn ein selten genutzter Zweig durchlaufen oder eine Erweiterung geladen wird.
Führen Sie die Tests mit der vorgesehenen Laufzeitumgebung und den Erweiterungen aus, die in Produktion erwartet werden. Ist die Testsuite begrenzt, ergänzen Sie manuelle oder automatisierte Prüfungen der Abläufe mit den größten Auswirkungen: Authentifizierung, Schreibvorgänge, gegebenenfalls Zahlungen, Dokumentenerstellung und wesentliche Integrationen. Erfassen Sie auch Fehler und Warnungen: Eine Änderung, die eine Warnung in eine Ausnahme verwandelt, kann einen Ablauf unterbrechen, bevor die Testsuite dies erkennt.
Die Arbeit so organisieren, dass sich Risiken eingrenzen lassen
Eine praktikable Reihenfolge ist, zunächst das vorgesehene Image oder die Zielkonfiguration samt Erweiterungen zu bestätigen, dann die Abhängigkeitsanforderungen aufzulösen und schließlich den Code und die Einstellungen zu korrigieren, die die Ausführung der Tests verhindern. Halten Sie jede Gruppe von Änderungen überprüfbar. Muss eine Bibliothek aktualisiert werden, dokumentieren Sie, welche Anforderung die Änderung nötig macht, und testen Sie die Bereiche der Anwendung, in denen sie verwendet wird.
Vermeiden Sie es, im selben Schritt wahllos alle Abhängigkeiten zu aktualisieren. Ein umfassendes Update kann notwendig sein, erhöht jedoch die Zahl der möglichen Ursachen, wenn eine Regression auftritt. Lässt sich das nicht trennen, halten Sie fest, welche Pakete geändert wurden, und ergänzen Sie gezielte Tests für die davon abhängigen Funktionen. Stellen Sie außerdem sicher, dass die Lock-Datei in CI und Produktion konsistent erzeugt und installiert wird.
Die Konfiguration muss dem tatsächlichen Ziel entsprechen. Eine Validierung mit einer Erweiterung, die nur in CI installiert ist, liefert ein irreführendes Signal; dasselbe gilt, wenn Hintergrundaufgaben weiterhin mit der vorherigen Laufzeitumgebung ausgeführt werden. Vergleichen Sie Images, Startbefehle, Variablen und Konfiguration zwischen Test- und Produktionsumgebung, bevor Sie ein Ergebnis dem Code zuschreiben.
In einer repräsentativen Umgebung validieren und Abbruchkriterien festlegen
CI sollte Installation, Analyse und Tests mit der vorgesehenen Laufzeitumgebung ausführen, nicht nur mit der aktuellen. Richten Sie nur dann separate Jobs für weitere Laufzeitumgebungen ein, wenn die Anwendung ein Kompatibilitätsfenster einhalten muss: In diesem Fall muss jede unterstützte Kombination explizit geprüft werden. Eine CI-Matrix kann zeigen, welche Kombinationen getestet werden, deckt aber Besonderheiten der Produktion nicht automatisch ab.
Verwenden Sie eine ausreichend realitätsnahe Staging-Umgebung, um den Start, kritische Abläufe, Integrationen, Queues und geplante Aufgaben zu prüfen. Kontrollieren Sie Protokolle, Fehler, Antwortzeiten und Ressourcenverbrauch vor und nach der Änderung. Legen Sie im Voraus fest, welches Verhalten die Bereitstellung stoppen würde, wer diese Entscheidung trifft und wie lange das System beobachtet wird. Schwellenwerte sollten sich an den Anforderungen der Anwendung und den verfügbaren Signalen orientieren, nicht an allgemeinen Richtwerten.
Zu brauchbaren Abnahmekriterien gehören: reproduzierbare Installation, vereinbarungsgemäß erfolgreiche Testsuite, geprüfte kritische Abläufe, keine neuen ungeklärten Fehler und die Fähigkeit, die Hintergrundprozesse zu betreiben. Dokumentieren Sie bekannte Ausnahmen und die jeweils verantwortliche Person. „Die Tests sind erfolgreich“ reicht nicht aus, wenn die Testsuite eine wesentliche Integration nicht abdeckt oder dem Team unbekannt ist, welche Metrik überwacht werden muss.
Mit einem datenkompatiblen Rollback bereitstellen
Wenn Architektur und Plattform es zulassen, aktivieren Sie die neue Laufzeitumgebung schrittweise: zunächst in einer kontrollierten Umgebung und anschließend für einen Teil des Datenverkehrs oder der Ausführungskapazität. Die schrittweise Aktivierung ist eine Bereitstellungsstrategie und keine Offenlegung von Informationen. Eine Verteilung der Anfragen auf mehrere Versionen ist nicht immer möglich – etwa bei zustandsbehafteten Prozessen oder Unterschieden im internen Protokoll. Planen Sie in diesem Fall einen koordinierten Übergang und prüfen Sie Sender und Empfänger von Nachrichten ausdrücklich.
Prüfen Sie vor der Bereitstellung, ob der vorherige Code im Fehlerfall wieder ausgeführt werden kann. Ein Rollback besteht nicht nur darin, ein Image wiederherzustellen: Eine Datenbankmigration, ein neues Nachrichtenformat oder ein inkompatibler Schreibvorgang kann verhindern, dass die vorherige Laufzeitumgebung die von der neuen erzeugten Daten lesen kann. Bevorzugen Sie schrittweise und kompatible Schemaänderungen: Erweitern Sie zuerst das Schema, stellen Sie dann Code bereit, der mit beiden Formen umgehen kann, und entfernen Sie das Alte erst, wenn es keine Verbraucher mehr gibt, die es benötigen. Legen Sie für jeden irreversiblen Schritt eine spezifische Wiederherstellung und eine Abbruchentscheidung fest.
Überwachen Sie während der Bereitstellung Anwendungs- und Laufzeitfehler, Ausfälle von Workern, Queue-Rückstände, geplante Aufgaben und relevante Geschäftssignale. Wird ein Rollback-Kriterium ausgelöst, stoppen Sie die Ausweitung der Änderung und folgen Sie dem erprobten Verfahren. Bewahren Sie die erforderlichen Protokolle auf, um die Ursache zu ermitteln; ein Rollback ohne Diagnose kann dazu führen, dass derselbe Fehler beim nächsten Versuch erneut auftritt.
Checkliste zur Beurteilung der Einsatzbereitschaft
- Sind Laufzeitumgebung und Erweiterungen für alle Umgebungen und Prozesse erfasst?
- Wurden die Composer-Anforderungen und Entwicklungstools geprüft?
- Werden Analysen und Tests mit der Zielkonfiguration ausgeführt?
- Wurden kritische Abläufe, Integrationen, Queues und geplante Aufgaben getestet?
- Sind die Unterschiede zwischen CI, Staging und Produktion bekannt?
- Gibt es betriebliche Signale, Verantwortliche und klare Kriterien für die Fortsetzung oder den Abbruch?
- Kann der vorherige Code mit den Daten und Nachrichten arbeiten, die die neue Version erzeugt?
- Wurde das Rollback erprobt, und ist bekannt, welche Änderungen sich nicht automatisch rückgängig machen lassen?
Die Entscheidung, die PHP-Version einer bestehenden Anwendung zu aktualisieren, ist fundierter, wenn das Team diese Fragen anhand von Nachweisen beantworten kann. Fehlen Tests oder ein Inventar, muss der nächste Schritt keine Neuentwicklung sein: Stattdessen können zunächst diese Lücken geschlossen und der Umfang der Änderung verkleinert werden. So werden mögliche Fehler erkannt, bevor sie sich auf Nutzer auswirken, und für jede Bereitstellungsentscheidung gibt es ein überprüfbares Kriterium.
