Setup: Wie wir unsere Laravel-Projekte einrichten

Laravel ist ein Open-Source-Framework für die Webentwicklung. Es bietet eine solide Grundlage für alle Arten von Webanwendungen und ist deshalb unsere erste Wahl für neue Projekte (näheres zur Funktion von Laravel erklären wir hier). Da die neueste Version von Laravel erst vor Kurzem veröffentlicht wurde, möchten wir unser Setup und einige Tipps mit euch teilen.

Diese Artikel-Serie über Laravel wird eine Mischung aus unserer Arbeitsweise, unseren Best Practices und einigen Tipps und Empfehlungen sein. Dieser Artikel ist für all jene gedacht, die sich für unsere Arbeitsweise interessieren oder die am Anfang eines neuen Laravel-Projekts stehen und sich orientieren wollen.

In diesem Sinne, let's get started.

Setup #

Bei jedem neuen Projekt steht zu Beginn das Setup. Wenn früher mehrere Personen an denselben Projekten gearbeitet haben, gab es immer das Problem der unterschiedlichen Umgebungen. Das änderte sich jedoch, als Docker und später Laravel Sail aufkamen und die Zusammenarbeit um einiges einfacher gemacht haben. Für uns bei bitperfect ist die Verwendung von Containern sowohl für neue als auch für bestehende Projekte ein absolutes Muss. Vom Start eines neuen Projekts bis hin zum Einrichten und Ausführen auf einem neuen Gerät vereinfachen Container und insbesondere Laravel Sail den Prozess für alle Beteiligten.

Für alle, die Sail nicht kennen: Es ist eine Kombination aus CLI-Tool und Docker-Setup, zugeschnitten auf Laravel und wird seit Laravel 8 vorinstalliert mitgeliefert.

Unser Tipp für ein neues Setup ist: Beachtet den Abschnitt "Choosing Your Sail Services" auf der Installationsseite. Unsere Standardeinstellungen sind PostgreSQL, Redis und wir fügen auch gerne das devcontainer-flag hinzu:

curl -s "https://laravel.build/bitperfect-default-setup?with=pgsql,redis&devcontainer" | bash

Mit diesem einzigen Befehl können neue Laravel-Installation so einfach wie noch nie eingerichtet und gestartet werden!

Basiskonfiguration und allgemeine Einstellungen #

Nach dem Einrichten eines neuen Projekts gibt es ein paar Einstellungen und Optionen, die wir für fast jedes Projekt empfehlen:

"strict models" aktivieren #

Eines der ersten Dinge, die wir in jeder neuen Anwendung tun, ist das Hinzufügen folgender Zeile zu unserem AppServiceProvider:

Model::shouldBeStrict();

Diese einfache Zeile verhindert drei Dinge:

• Ein nachträgliches Laden von Beziehungen,
• das stille Ignorieren von nicht ausfüllbaren Attributen in Massenzuweisungen und
• den Zugriff auf nicht existierende Attribute.

Warum ist das wichtig? Ganz einfach, weil es potenzielle Probleme transparent macht.

Beispiele und zusätzliche Informationen bietet Laravel News in einem ausgezeichneten Artikel, warum man das Modell shouldBeStrict verwenden sollte, wenn man eine neue Laravel-App entwickelt.

Anpassen der Konfiguration #

Laravel wird standardmäßig mit einer Vielzahl von Standardkonfigurationen und einer umfangreichen Beispiel-"env"-Datei geliefert. Diese Standardeinstellungen funktionieren im Allgemeinen gut für die meisten Projekte. Es gibt jedoch einige Dinge, die wir gerne sofort anpassen:

• Ändern des Standard-App-Namens in den tatsächlichen App-Namen in config/app.php.
• Ändern des Standard-Logkanals auf täglich in config/logging.php
• Ändern des Cache-Treibers auf redis in config/cache.php (natürlich nur, wenn wir redis im Projekt verwenden)

Im Allgemeinen versuchen wir nur jene Dinge in den env - Dateien oder Variablen zu belassen, die auch wirklich vom Environment abhängig sind. Alles andere ändern wir direkt in den configs. Auf diese Weise bleiben die Umgebungsparameter schlank. Geheimnisse wie Passwörter und Zugangsschlüssel sind hier natürlich eine Ausnahme. Sensible Informationen sollten niemals in den Konfigurationsdateien stehen.

Hinzufügen eines Code Style Fixers #

Ein einheitlicher Code-Stil ist wichtig. Er ist sogar umso wichtiger, sobald mehr als eine Person an einem Projekt arbeitet. Ein einheitlicher Code-Stil verhindert nicht nur unnötige Ausuferungen in Form von Whitespace-Änderungen in Pull-Requests, sondern fördert auch die Lesbarkeit des Codes.

Für uns sind Tools, die bestimmte Code-Stile erzwingen, längst zum Standard für jedes Projekt geworden. Unser bevorzugtes Tool ist schon seit einiger Zeit Prettier. Es ist einfach einzurichten und funktioniert gut für Laravel-Projekte mit dem Prettier PHP Plugin. Mit Laravel Pint gibt es auch eine Laravel-native Option.

Welcher Code Style Fixer zum Einsatz kommt, ist aber meist nebensächlich - Hauptsache es wird einer verwendet. Noch besser ist, wenn zusätzlich auch die CI-Pipeline den Code-Style überprüft!

Hinzufügen eines Linters und eines Test-Setups #

Eine statische Code-Analyse ist ein weiteres Muss für unsere Projekte. Für das Linting in Laravel-Projekten nutzen wir PHPStan mit dem LaraStan Wrapper. Auf diese Weise können wir Probleme mit unbenutztem oder totem Code, unbenutzten Variablen und fehlenden Typen leicht erkennen.

Zum Testen verwenden wir das Standard-Setup, so wie es mit der Laravel-Installation ausgeliefert wird. Das Schreiben von Tests kann anfangs nach viel zusätzlicher Arbeit aussehen, aber auf lange Sicht lohnt sich der zusätzliche Aufwand. Wenn Sie Ihre Anwendung mit der Gewissheit aktualisieren, dass nichts kaputt geht, können Sie beruhigt sein und nachts ruhig schlafen.

CI/CD-Pipeline und Deployment #

Was wir ebenfalls empfehlen, ist die Einrichtung einer automatisierten Pipeline für das Erstellen, Prüfen, Testen und Bereitstellen des Projekts. Unserer Erfahrung nach hat die frühzeitige Einrichtung dieser Pipeline zwei große Vorteile: Erstens haben Entwickler:innen viel mehr Zeit und Durchläufe, um eventuelle Fehler im Prozess zu finden und auszubügeln, als wenn die Pipeline erst kurz vor dem Go-Live einrichtet wird. Zweitens erhalten die Entwickler:innen sofortige Rückmeldung, wenn sie etwas versuchen, das in der Pipeline oder bei der Bereitstellung nicht funktioniert. Das zwingt sie dazu, sich frühzeitig gute Praktiken anzueignen, wie z. B. die korrekte Verwaltung der Migrationen, Einstellungen, Umgebungen etc.

Was wir immer in unsere Laravel-Pipelines aufnehmen:

• Überprüfung des Code-Stils (selbst wenn die automatische Formatierung eingerichtet ist, kann unserer Erfahrung nach manchmal etwas schief gehen und falsch formatierter Code gelangt in das Repository. Die Pipeline ist ein hervorragender Schutz für diese Fälle)
• Linting
• Ausführen der Tests
• Deployment

Für das Deployment verwenden wir eine Vielzahl von Hostern und Diensten. Unserer Erfahrung nach läuft Laravel in fast jeder Umgebung gut. Für unsere aktuellsten Projekte arbeiten wir mit Laravel Forge und der Hetzner Cloud und können sie bisher sehr empfehlen. Es macht das Einrichten von Servern, Konfigurations- und Umgebungsparametern, Deployment, Backups, Queues und allem weiteren zu einem Kinderspiel.