Succesvol implementeren. Vervolgens fout 500: klasse niet gevonden. Iemand heeft 'composer update' rechtstreeks op de server uitgevoerd, de PHP-opdrachtregelversie is 8.1 terwijl PHP-FPM 8.2 draait, en het lock-bestand is niet vastgelegd in de repository. Componist in productie is geen live pakketbeheerder — het is een reproduceerbaar installatieprogramma vanuit een vaste vergrendeling, stroomopwaarts gevalideerd.
Deze scène herhaalt zich elke week op aangepaste Laravel-, Symfony- of PHP-projecten. Het goede nieuws: de juiste route komt neer op een paar eenvoudige regels. Het slechte: één enkele uitzondering is genoeg om van een implementatie een loterij te maken.
installeren versus updaten: de gouden regel
Het onderscheid tussen 'composer install' en 'composer update' is niet syntactisch; het scheidt twee werelden.
| Bestel | Waar moet u het uitvoeren | Effect |
|---|---|---|
componistupdate | Lokaal of ontwikkelings-CI | Berekent versies opnieuw volgens composer.json |
componist installeren | Bouw of productie CI | Reproduceert exact de vastgelegde vergrendeling |
install --no-dev | Productie | Exclusief require-dev-afhankelijkheden |
install -o / --optimize-autoloader | Productie | Prestatiegeoptimaliseerde PSR-autoloader |
'update opstellen' in productie betekent lottrekking voor de versies die vanavond de betaling zullen verbreken.
Tijdens de ontwikkeling update je, test je, en voer je de nieuwe vergrendeling vast. In productie installeer je wat al gevalideerd is – niets meer en niets minder.
Aanbevolen implementatiepijplijn
Optie A — continue integratieopbouw, implementatie van artefacten. Continue integratie voert composer install --no-dev -o uit en test vervolgens. Het archiveert de release (code plus leverancier, of afzonderlijke leverancier). De productie extraheert het artefact en start de services opnieuw — zonder Composer op de live server te starten. Deze aanpak verdient de voorkeur wanneer het verkeer of het team uit meer dan één persoon bestaat.
Optie B — Componeer op de server. Je krijgt een onveranderlijke Git-tag, voert composer install --no-dev -o --no-interaction uit, migreert vervolgens, maakt de cache leeg en laadt PHP-FPM opnieuw. Acceptabel voor kleine projecten, maar kwetsbaar als het servergeheugen beperkt is of het netwerk instabiel is.
Veelvoorkomende valkuilen in de productie
PHP CLI verschilt van PHP-FPM: een ontbrekende opdrachtregelextensie blokkeert de installatie of genereert een autoloader die niet compatibel is met de webruntime.
Onvoldoende geheugen: grote Symfony- of Laravel-projecten verbruiken tijdens de installatie enkele honderden megabytes. Plan voor continue integratie of een geschikte geheugenlimiet.
Onjuiste machtigingen: een leveranciersmap die door de webgebruiker kan worden bewerkt, wordt een beveiligingsprobleem.
Ontwikkelingspakket lek: het vergeten van --no-dev stelt PHPUnit of andere tools bloot als de webconfiguratie niet op de juiste manier is vergrendeld.
Configuratieplatform: het veld config.platform.php in composer.json stemt de afhankelijkheidsresolutie af op de doelversie, zelfs als de lokale machine nieuwer is.
Wat de host moet toestaan
Controleer of Composer 2.x beschikbaar is via SSH, dat de PHP-opdrachtregelversie overeenkomt met PHP-FPM, dat Git of een implementatiehook toegankelijk is en dat er voldoende geheugen is voor een installatie - of dat de host de implementatie van artefacten ondersteunt zonder Composer aan de serverzijde.
Raadpleeg onze handleidingen Symfony en Laravel in production voor de stappen na Componist.
De top: de componist loopt vast, hij beslist niet tijdens de productie
Beslis en ga vooruit zonder blinde vlek
Combineer het composer.lock-bestand naar de repository en behandel eventuele wijzigingen als codewijzigingen die moeten worden getest. Configureer continue integratie om composer install --no-dev -o uit te voeren, gevolgd door testen vóór enige implementatie. Plaats PHP CLI en PHP-FPM op dezelfde versie en extensies. Geef de voorkeur aan de implementatie van artefacten zodra het verkeer of het team dit rechtvaardigt. Documenteer het exacte commando dat tijdens de productie wordt gebruikt, zodat niemand op vrijdagavond een update improviseert.
Veelgestelde vragen
Moeten we de componistupdate uitvoeren tijdens de productie?
Nee. De productie voert 'composer install' uit vanuit een vergrendelingsbestand dat is vastgelegd in de repository. Het update commando herberekent nieuwe versies van afhankelijkheden - het is gereserveerd voor de ontwikkelomgeving of continue integratie, na uitvoering van geautomatiseerde tests.
Waarom --geen ontwikkelaar in productie?
PHPUnit en ontwikkelingstools vergroten het aanvalsoppervlak en de omvang van de leveranciersmap. Ze mogen niet aanwezig zijn op een productieserver, waar elk onnodig pakket een gateway of een knelpunt bij de implementatie kan worden.
Moet composer.lock een versienummer hebben?
Ja voor applicaties (Laravel, Symfony, maatwerkproject). Nee voor gepubliceerde Composer-bibliotheken. Voor een site of een applicatie garandeert het slot reproduceerbaarheid tussen ontwikkelaars, continue integratie en productie.
Componist installeert geheugenfout?
Je kunt de limiet tijdelijk verhogen met COMPOSER_MEMORY_LIMIT=-1 of swap toevoegen. Beter nog: voer de installatie uit in continue integratie en implementeer een artefact met de leveranciersmap.
In de productie herhaalt Composer: er wordt niet geïmproviseerd. Als het slot ontbreekt, geldt dat ook voor de inzet.