Erfolgreich bereitstellen. Dann Fehler 500: Klasse nicht gefunden. Jemand hat „Composer Update“ direkt auf dem Server ausgeführt, die PHP-Befehlszeilenversion ist 8.1, während PHP-FPM 8.2 ausführt, und die Sperrdatei wurde nicht in das Repository übernommen. Composer in der Produktion ist kein Live-Paketmanager – es ist ein reproduzierbares Installationsprogramm aus einer festen Sperre, das im Upstream validiert wird.
Diese Szene wiederholt sich jede Woche bei benutzerdefinierten Laravel-, Symfony- oder PHP-Projekten. Die gute Nachricht: Die richtige Route hängt von ein paar einfachen Regeln ab. Das Schlechte: Eine einzige Ausnahme reicht aus, um einen Einsatz in eine Lotterie zu verwandeln.
Installation vs. Update: die goldene Regel
Die Unterscheidung zwischen „Composer-Installation“ und „Composer-Update“ ist nicht syntaktisch – sie trennt zwei Welten.
| Bestellen | Wo soll es ausgeführt werden | Wirkung | |
|---|---|---|---|
Composer-Update | Lokales oder Entwicklungs-CI | Berechnet Versionen gemäß Composer.json | neu |
composer install | Build- oder Produktions-CI | Reproduziert exakt die festgeschriebene Sperre | |
install --no-dev | Produktion | Ausgeschlossen sind require-dev-Abhängigkeiten | |
install -o / --optimize-autoloader | Produktion | Leistungsoptimierter PSR-Autoloader |
„Update erstellen“ in der Produktion bedeutet, dass die Versionen ausgelost werden, bei denen die Zahlung heute Abend unterbrochen wird.
In der Entwicklung aktualisieren Sie absichtlich, Sie testen, Sie übernehmen die neue Sperre. In der Produktion installieren Sie, was bereits validiert wurde – nicht mehr und nicht weniger.
Empfohlene Bereitstellungspipeline
Option A – Continuous Integration Build, Artefaktbereitstellung. Continuous Integration führt „composer install --no-dev -o“ aus und testet dann. Es archiviert die Version (Code plus Anbieter oder separater Anbieter). Die Produktion extrahiert das Artefakt und startet die Dienste neu – ohne Composer auf dem Live-Server zu starten. Dies ist der bevorzugte Ansatz, wenn der Verkehr oder das Team mehr als eine Person umfasst.
Option B – Auf dem Server komponieren. Sie erhalten ein unveränderliches Git-Tag, führen „composer install --no-dev -o --no-interaction“ aus, migrieren dann, leeren den Cache und laden PHP-FPM neu. Akzeptabel für kleine Projekte, aber fragil, wenn der Serverspeicher begrenzt ist oder das Netzwerk instabil ist.
Häufige Fallstricke in der Produktion
PHP-CLI unterscheidet sich von PHP-FPM: Eine fehlende Befehlszeilenerweiterung blockiert die Installation oder generiert einen Autoloader, der mit der Web-Laufzeitumgebung nicht kompatibel ist.
Unzureichender Speicher: Große Symfony- oder Laravel-Projekte verbrauchen während der Installation mehrere hundert Megabyte. Planen Sie eine kontinuierliche Integration oder eine entsprechende Speicherbegrenzung ein.
Falsche Berechtigungen: Ein vom Webbenutzer bearbeitbarer Anbieterordner stellt eine Sicherheitslücke dar.
Entwicklungspaketleck: Das Vergessen von „--no-dev“ macht PHPUnit oder andere Tools verfügbar, wenn die Webkonfiguration nicht ordnungsgemäß gesperrt ist.
Konfigurationsplattform: Das Feld „config.platform.php“ in Composer.json richtet die Abhängigkeitsauflösung auf die Zielversion aus, auch wenn der lokale Computer neuer ist.
Was der Gastgeber zulassen muss
Stellen Sie sicher, dass Composer 2.x über SSH verfügbar ist, dass die PHP-Befehlszeilenversion mit PHP-FPM übereinstimmt, dass Git oder ein Deployment-Hook zugänglich ist und dass genügend Speicher für eine Installation vorhanden ist – oder dass der Host die Bereitstellung von Artefakten ohne Composer auf der Serverseite unterstützt.
Informationen zu den Post-Composer-Schritten finden Sie in unseren Leitfäden Symfony und Laravel in Produktion.
Der Gipfel: Der Komponist friert ein, er entscheidet nicht in der Produktion
Entscheide dich und gehe ohne blinden Fleck voran
Übertragen Sie die Datei „composer.lock“ in das Repository und behandeln Sie alle Änderungen als zu testende Codeänderungen. Konfigurieren Sie die kontinuierliche Integration so, dass vor jeder Bereitstellung „composer install --no-dev -o“ ausgeführt und anschließend getestet wird. Richte PHP CLI und PHP-FPM auf dieselbe Version und dieselben Erweiterungen aus. Bevorzugen Sie die Bereitstellung von Artefakten, sobald der Datenverkehr oder das Team dies rechtfertigen. Dokumentieren Sie den genauen Befehl, der in der Produktion verwendet wird, damit niemand an einem Freitagabend ein „Update“ improvisiert.
Häufig gestellte Fragen
Sollten wir das Composer-Update in der Produktion ausführen?
Nein. Die Produktion führt die „Composer-Installation“ über eine im Repository festgeschriebene Sperrdatei aus. Der Befehl „update“ berechnet neue Versionen von Abhängigkeiten neu – er ist nach der Ausführung automatisierter Tests für die Entwicklungsumgebung oder die kontinuierliche Integration reserviert.
Warum --no-dev in prod?
PHPUnit und Entwicklungstools erhöhen die Angriffsfläche und die Größe des Herstellerordners. Sie sollten nicht auf einem Produktionsserver vorhanden sein, wo jedes unnötige Paket zu einem Gateway oder einem Bereitstellungsengpass werden kann.
Sollte Composer.lock versioniert werden?
Ja für Anwendungen (Laravel, Symfony, benutzerdefiniertes Projekt). Nein für veröffentlichte Composer-Bibliotheken. Für eine Site oder eine Anwendung garantiert die Sperre Reproduzierbarkeit zwischen Entwicklern, kontinuierliche Integration und Produktion.
Composer-Installationsspeicherfehler?
Sie können das Limit vorübergehend mit „COMPOSER_MEMORY_LIMIT=-1“ erhöhen oder Swap hinzufügen. Besser noch: Führen Sie die Installation in kontinuierlicher Integration aus und stellen Sie ein Artefakt bereit, das den Herstellerordner enthält.
Bei der Produktion wiederholt Composer: Es wird nicht improvisiert. Fehlt die Sperre, fehlt auch die Bereitstellung.