Laravel-Entwicklung in München für Enterprise-Kunden

München kauft Entwicklung über einen Prozess ein, und der Prozess ist der größere Teil des Zeitplans. Versicherer, Hersteller, industrienahe Dienstleister und die Beratungen, die an sie verkaufen: Einkauf, Lieferanten-Onboarding, Sicherheitsfragebogen, Architekturgremium.

Die Technik ist selten das, was diese Projekte verspätet.

Was ein Münchner Projekt aufhält

Warten auf eine Staging-Umgebung, auf Verzeichniszugang, auf einen Sicherheitsfragebogen, auf die eine Person, die eine Firewall-Regel freigeben kann.

Deshalb steht in Woche eins eine Liste der Zugänge, die wir brauchen, mit der jeweils längsten Vorlaufzeit daneben. Danach wird geschnitten - jede Phase so, dass sie mit den Zugängen auskommt, die bis dahin da sein können. Das ist Beschaffungsarbeit und keine Entwicklung, und sie entscheidet den Liefertermin häufiger als jede technische Frage.

In München stehen die Systeme im Haus

Das ist die Münchner Besonderheit, die Architektur verändert und nicht nur Details.

ERP, Lagerverwaltung, Produktionsplanung - die laufen hier häufig auf einer Maschine im eigenen Netz und nicht als gehosteter Dienst mit öffentlichem Endpunkt. Eine deployte Anwendung erreicht sie nicht, und keine Bibliothek ändert das.

Es gibt drei ehrliche Formen, und die Wahl ist ein Gespräch mit Ihrer IT, keine technische Vorliebe. Ein Konnektor in Ihrem Netz, der nach außen über HTTPS spricht, sodass keine eingehende Firewall-Regel nötig ist. Ein privater Netzpfad, sauberer zu durchdenken, sobald es ihn gibt - und es gibt ihn, wenn Ihre IT Zeit hat. Oder ein Dateiaustausch, den API-Liebhaber zu schnell abtun: er ist beobachtbar, ein fehlgeschlagener Lauf lässt die Datei liegen, und ein Mensch kann sie öffnen und sehen, was nicht stimmte.

Wie auch immer: die Folge ist dieselbe und gehört in die erste Woche gesagt - die Daten in der Anwendung sind eine Kopie mit Verzögerung, und die Oberfläche muss das sagen, statt einen alten Wert als aktuell auszugeben. Das ist die Integrationsfrage, mit der hier jedes Projekt beginnt.

Alte Laravel-Anwendungen, und warum man nicht neu anfängt

Ein guter Teil dieser Arbeit ist eine fünf bis fünfzehn Jahre alte Anwendung, auf die sich das Geschäft stützt, gebaut von Leuten, die gegangen sind.

Der Reflex ist die Neuentwicklung. Er ist fast immer falsch, und der Grund ist keine Sentimentalität: Jahre an Geschäftsregeln stecken dort und sonst nirgends - die Ausnahmen für drei große Kunden, der Workaround für das, was ein Partnersystem dienstags tut, die Rundungsregel, über die 2019 gestritten wurde. Nichts davon ist dokumentiert, und eine Neuentwicklung entdeckt es über Fehlermeldungen derjenigen wieder, die darauf angewiesen sind.

Mehrere Versionen Rückstand haben messbare Kosten, und der Vergleich mit einer Neuentwicklung fällt meist deutlich aus. Die ehrliche Ausnahme ist ein falsches Datenmodell statt alten Codes, und das sagen wir, wenn es so ist.

Ein Münchner On-Premise-Betrieb hat keine Managed Services

Im Haus gibt es keine managed Queue, keinen managed Object Store, keine managed Suche und keine Plattform, die beim Push neu deployt. Es gibt eine virtuelle Maschine, ein Wartungsfenster und ein Betriebsteam mit eigenen Abläufen.

Das ist machbar, und man muss dafür entwerfen statt es zu entdecken. Jeder Managed Service, auf den sich die Anwendung sonst stützen würde, wird zu einer Komponente, die jemand betreiben muss - also entscheidet man bewusst. Redis auf demselben Host, oder die Datenbank als Queue-Backend. Das Dateisystem hinter derselben Storage-Abstraktion, die sonst auf einen Object Store gezeigt hätte. Volltextsuche in Postgres statt einer eigenen Engine, sofern die Anforderung das zweite zu betreibende System nicht wirklich rechtfertigt.

Gegen Abstraktionen zu programmieren statt gegen einen Anbieter macht daraus eine Konfigurationsentscheidung statt eines Rewrites, und es ist dieselbe Disziplin, die die Anwendung später beweglich hält. Die Kosten sind gering. Die Alternative ist eine Anwendung, die eine Plattform voraussetzt und auseinandergenommen werden muss, um irgendwo anders zu laufen.

Das Deployment gehört ihnen. Das heißt, was wir übergeben, muss ihr Prozess annehmen können - eine dokumentierte, wiederholbare Abfolge, die ohne unsere Anwesenheit läuft, in ein Wartungsfenster passt und von der Person zurückgenommen werden kann, die Dienst hat. Migrationen, die sicher vor dem neuen Code laufen, und ein Rollback, das keine Datenbankwiederherstellung braucht, machen das möglich.

Backups und Monitoring gehören ebenfalls ihnen, und die Übergabe ist nicht fertig, bevor jemand auf ihrer Seite einmal unter Zeugen aus einem Backup zurückgespielt hat. Ein ungetestetes Backup ist ein Vorhaben, kein Backup.

Eine Münchner Laravel-Anwendung fünf Versionen zurück aktualisieren

Die Anwendung läuft, sie ist seit Jahren aus dem Support, und die Frage ist, ob man aktualisiert oder ersetzt. Aktualisieren ist fast immer die richtige Antwort und wird fast immer unterschätzt.

Die Reihenfolge geben die Abhängigkeiten vor, nicht die Vorliebe. PHP zuerst, weil die Framework-Version, auf die man zielt, es verlangt und das Extension-Ökosystem sich beschwert. Dann eine Framework-Version nach der anderen, mit der Testsuite dazwischen. Zwischenversionen zu überspringen ist verlockend und beseitigt das Einzige, was verrät, welche Änderung etwas zerbrochen hat.

Das setzt voraus, dass es eine Testsuite gibt, und in einer Anwendung dieses Jahrgangs gibt es sie meistens nicht. Eine von Null zu schreiben ist nicht die Aufgabe. Einen Test um die paar Pfade zu legen, die den Umsatz erzeugen, ist es - und das ist eine Woche, kein Quartal. Ohne das ist die Aktualisierung eine Folge von Änderungen, die niemand prüfen kann, und sie wird auf halber Strecke abgebrochen, mit der Anwendung in einem schlechteren Zustand als zu Beginn.

An den Paketen bleibt es hängen. Ein aufgegebenes Paket ohne Version für das Zielframework muss ersetzt, einverleibt oder entfernt werden, und diese Fälle vorher zu finden statt bei Version vier von fünf verändert die Schätzung deutlich. Diese Bestandsaufnahme ist ein Tagewerk und der Unterschied zwischen einem Plan und einer Hoffnung.

Was man einem Sponsor sagen sollte, der das gegen einen Neubau abwägt - die Aktualisierung erhält das Verhalten, von dem das Geschäft abhängt, einschließlich der Teile, die niemand dokumentiert hat. Ein Neubau entdeckt sie wieder, eine Beschwerde nach der anderen.

Die Formalitäten gehören dazu

Die Rechnung stellt die Codefacture Yazılım A.Ş. aus, eingetragen in der Türkei, in Euro per Überweisung und ohne türkische Umsatzsteuer, da exportierte Leistungen davon befreit sind.

Ein Sicherheitsfragebogen fragt nach Datenstandort, Unterauftragnehmern und dem, was am Projektende geschieht. Beantwortbar, und vorher schneller als mittendrin.

Der regulatorische Rahmen steht auf der Länderseite Deutschland.