Laravel-Agentur für Anwendungen, die schon laufen

Zuerst auf einen PHP-Stand, für den es noch Sicherheitsupdates gibt – ohne ihn lässt sich Laravel gar nicht anheben. Danach Laravel Version für Version, jede Stufe mit den Breaking Changes aus der offiziellen Upgrade-Anleitung, jede Stufe einzeln lauffähig und einzeln abgenommen. Ziel ist eine Version, die noch gepflegt wird, nicht der neueste Stand um jeden Preis: Wie weit eine Stufe reicht, bestimmen meist die Pakete, deren Hersteller sie aufgegeben hat. Wo es keinen Nachfolger gibt, ersetzen wir das Paket oder lösen die Funktion durch eigenen Code ab – mit dem Preis dafür im Angebot, bevor die Stufe beginnt.

Am Befund zu Ihrer eigenen Anwendung. Darin steht, welcher Stand in der Datei composer.lock festgeschrieben ist, welche eigenen Eingriffe am Framework die Updates blockieren, ob Worker für jede Warteschlange und der Scheduler tatsächlich laufen, welche Migrationen keinen Rückweg haben und an welchen Stellen Tests fehlen, obwohl dort Geld und Fristen hängen. Gibt es kein Repository, legen wir vor dem ersten Lesen eines an und sichern darin den Stand, der produktiv läuft; geändert wird nichts, bevor Sie den Befund gesehen haben. Benannte Laravel-Projekte führen wir dagegen nicht, und wir erfinden keine – was als Firma hinter uns steht, lesen Sie oben an den Zahlen.

Ihnen. Am eigens für Sie erstellten Code gehen die Nutzungsrechte mit vollständiger Bezahlung auf Sie über; Repository, Server und Domain laufen auf Ihren Namen. Fremde Pakete behalten ihre eigenen Lizenzen – welche das sind und was sie erlauben, steht in der Liste der Abhängigkeiten, die zur Übergabe gehört.

Planung, Aufgabenverteilung und Weisungen liegen bei unserem Projektleiter, er ist auch Ihr Ansprechpartner. Sie beschreiben das Ziel, entscheiden über die Reihenfolge und nehmen gegen die vereinbarten Kriterien ab. Grundlage ist ein Werkvertrag mit abgegrenztem Leistungsumfang, nicht ein offenes Stundenkonto.

Wir, und zwar bevor Ihre Kunden anrufen. Zum Betrieb gehört eine Überwachung, die mehr prüft als die Erreichbarkeit der Startseite: Läuft für jede Warteschlange ein Worker, ist der Scheduler im Cron aktiv, wie alt ist der älteste wartende Auftrag, wie viele sind in die Fehlertabelle gelaufen. Bleibt etwas stehen, meldet es sich bei uns. Die Schritte für Neustart und Nacharbeit stehen in der Betriebsanleitung, die Entscheidungen im Projekttagebuch – auch für den Fall, dass bei uns jemand ausfällt und eine andere Person übernimmt.

Das entscheidet der Befund, nicht das Alter der Version. Steckt die Fachlogik verständlich in der Anwendung, ist das Upgrade fast immer der kürzere Weg. Liegt der Aufwand dagegen in eigenen Eingriffen am Framework und in Paketen ohne Nachfolger, rechnen wir beide Wege gegeneinander und legen Ihnen die Zahlen vor.

Nach 14 Tagen liegt ein erstes Ergebnis vor: der Befund mit Reihenfolge und die ersten geschlossenen Sicherheitsfunde. Der erste Abschnitt im Tagesbetrieb folgt in der Regel nach 2–6 Wochen. Wie viele Stufen dazwischen liegen, hängt daran, wie weit die heutige Version vom nächsten gepflegten Stand entfernt ist.