Laravel-Wartung & Support

Die meisten Laravel-Anwendungen werden von denen gewartet, die sie gebaut haben – bis diese Person geht. Was folgt, ist vertraut: Niemand aktualisiert etwas, weil niemand sicher ist, was dabei kaputtgeht, die Liste der Abhängigkeiten altert still vor sich hin, und das erste ernsthafte Problem kommt zur schlechtestmöglichen Stunde, ohne dass jemand da wäre, der weiß, wo die Leichen liegen.

Das hier ist die Vereinbarung, die das verhindert – für Unternehmen, deren Anwendung wichtig ist, aber kein festes Laravel-Team rechtfertigt.

Was Laravel-Wartung und -Support abdeckt

Sicherheitspatches, zügig eingespielt. Laravel, PHP und Ihr Abhängigkeitsbaum veröffentlichen alle Hinweise. Die meisten sind für Sie belanglos und einige nicht, und zu wissen welche welche sind, ist die Arbeit. Patches innerhalb des unterstützten Bereichs gehen nach Plan raus; alles Dringende geht raus, wenn es bekannt wird, und nicht beim nächsten passenden Release.

Abhängigkeiten bleiben installierbar. Der teure Fehler ist nicht ein veraltetes Paket – er ist die Entdeckung an dem Tag, an dem Sie etwas hinzufügen müssen, dass sich nichts Neues installieren lässt, weil die Constraints nicht mehr auflösbar sind. Diesen Graphen gesund zu halten ist eine kleine monatliche Aufgabe und ein gewaltiges Einmalprojekt.

Das Framework bleibt im Support. Ein Minor-Upgrade jedes Mal, wenn eines erscheint, und ein Major-Upgrade geplant statt aufgeschoben. Der Unterschied zwischen einer Anwendung, die eine Version zurückliegt, und einer, die drei zurückliegt, ist nicht das Dreifache an Arbeit – er ist der Grund, warum Upgrades und Rettung als eigenes Projekt existiert.

Jemand am anderen Ende. Ein Weg zu einem Entwickler, der Ihr Schema, Ihre Queues und Ihr Deployment bereits kennt, damit ein Vorfall mit einer Diagnose beginnt und nicht mit einer Orientierung.

Monitoring, das etwas bedeutet. Fehlgeschlagene Jobs, Queue-Tiefe, Fehlerraten und die Endpunkte, die Geld tragen – beobachtet, mit Schwellwerten, die mit Ihnen abgestimmt sind, damit die erste Meldung eines Problems nicht von einem Kunden kommt.

Was nicht abgedeckt ist

Neue Funktionen. Das ist Absicht und nicht Knauserei: Ein Wartungsvertrag, der Funktionsarbeit aufsaugt, wird zu einem langsamen, ungeplanten Entwicklungsbudget, und die Wartung hört auf zu passieren, weil Funktionen immer dringender sind. Funktionsarbeit wird als Funktionsarbeit angeboten, und die beiden konkurrieren nicht um dieselben Stunden.

Wie es läuft, und was ein Laravel-Retainer voraussetzt

Wir beginnen damit, die Anwendung zu lesen, egal ob wir sie geschrieben haben oder nicht – den Abhängigkeitsgraphen, den Deployment-Pfad, die Jobs, die Integrationen und was auch immer Leute nachts wachhält. Daraus entsteht ein kurzes Dokument: was brüchig ist, was aus dem Support gefallen ist, und was um drei Uhr morgens passieren würde.

Danach ist es ein monatlicher Rhythmus. Patches und Updates gehen nach einem Plan raus, den Sie vorher kennen. Alles Dringende unterbricht ihn. Jeder Monat endet mit einer Notiz, was sich geändert hat und was ansteht – das Dokument, nach dem Ihr Prüfer fragt, und das, über das Ihr nächster Entwickler froh sein wird.

Alles passiert in Ihrem Repository, als prüfbare Pull Requests. An Ihrem System wird nichts getan, was Sie hinterher nicht nachlesen können.

Worauf ein Laravel-Supportzeitraum tatsächlich verpflichtet

"Unterstützt" bedeutet zwei verschiedene Dinge, und der Unterschied entscheidet, wann ein Major-Upgrade terminiert werden muss.

Ein Release erhält für eine Zeit Fehlerbehebungen und für längere Zeit Sicherheitsfixes. Ist das zweite Datum vorbei, wird eine offengelegte Schwachstelle im Framework für Ihre Version gar nicht mehr behoben - das Mittel ist das Upgrade, durchgeführt unter Zeitdruck, was der schlechteste Umstand dafür ist.

Der Kalender von PHP selbst ist die härtere Frist und die, die Teams weniger verfolgen. Eine PHP-Version erhält ab einem veröffentlichten Datum keine Sicherheitsfixes mehr, und danach wird Ihr Hoster sie irgendwann nicht mehr anbieten, was ein Planungsproblem in eine Kündigung verwandelt. Die Framework-Version, die Sie fahren können, ist von der PHP-Version begrenzt, und die PHP-Version von dem, was Ihr Hoster unterstützt - die drei Daten müssen also zusammen betrachtet werden und nicht einzeln.

Praktisch heißt das eine Tabelle mit drei Zeilen und dem nächsten Datum in jeder, quartalsweise durchgesehen statt entdeckt. Der nützliche Output sind nicht die Daten - es ist, im September zu wissen, dass das Upgrade in die Januarplanung gehört, solange es noch eine Entscheidung über den Zeitpunkt ist.

Der Laravel-Scheduler und der Worker, den niemand beobachtet

Der häufigste stille Ausfall in einer Laravel-Anwendung ist kein Fehler. Es ist ein geplanter Befehl, der aufgehört hat zu laufen - denn Abwesenheit erzeugt keine Logzeile, und Erfolg erzeugt auch keine.

Es gibt drei Wege dorthin und alle drei sind unsichtbar. Der Cron-Eintrag, der den Scheduler aufruft, wurde bei einer Servermigration entfernt. Der Scheduler läuft, aber der Befehl bricht jede Nacht früh ab und die Ausgabe landet in einer Datei, die niemand liest. Oder der Befehl läuft noch und seine Arbeit schlägt seit Wochen still fehl, weil ein Dritter eine Antwort geändert hat.

Queue-Worker scheitern anders und feiner. Ein Worker hält den Anwendungscode, mit dem er gestartet ist - ein Deploy, der die Worker nicht neu startet, lässt also den Code von gestern die Jobs von heute verarbeiten. Das erzeugt Verhalten, das niemand reproduzieren kann und das alle auf Caching schieben. Der Neustart muss Teil des Deploys sein und kein Schritt, den sich jemand merkt, und ein gestorbener Worker muss von einem Prozess-Supervisor zurückgebracht werden und nicht davon, dass es jemand bemerkt.

Was überwacht wird, ist deshalb bewusst klein und konkret. Der letzte erfolgreiche Lauf jeder geplanten Aufgabe, mit Alarm, wenn einer überfällig ist. Queue-Tiefe und das Alter des ältesten wartenden Jobs. Die Tabelle der fehlgeschlagenen Jobs, mit einem Schwellwert statt einem Dashboard. Drei Signale, mit Ihnen abgestimmt, die zusammen fast alles erwischen, was in einer Anwendung mit Arbeit außerhalb des Requests leise schiefgeht.

Wann das hier das Falsche ist

Wenn die Anwendung bereits mehrere Versionen zurückliegt und schwer zu ändern ist, ist Wartung nicht der Ausgangspunkt – das Upgrade ist es, und etwas anderes zu behaupten heißt, monatlich dafür zu zahlen, eine Position zu halten, die immer schlechter wird.

Wenn niemand sagen kann, ob die Anwendung gesund ist, beantwortet das Audit das in zwei Wochen zum Festpreis, und die Antwort entscheidet, welches dieser Projekte Sie tatsächlich brauchen.

Was Sie aus der Laravel-Wartung bekommen

Eine monatliche schriftliche Notiz: was gepatcht wurde, was aktualisiert wurde, was wir bewusst nicht angefasst haben und warum, und die verbrauchten Stunden gegen die gebuchten. Die Arbeit selbst kommt als Pull Requests, und was schiefgeht, bekommt eine Aufarbeitung, die länger ist als eine Zeile im Chat.

Der erste Monat bringt zusätzlich eine kurze Bestandsaufnahme der Anwendung. Versionen, Abhängigkeiten mit bekannten Problemen und die drei Dinge, die am ehesten jemanden aus dem Bett holen. Dieses Dokument nützt Ihnen, ob die Vereinbarung weiterläuft oder nicht.