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 abgedeckt ist

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

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.

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 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.