Checklist pro nasazení Laravel aplikace do produkce

Nasazení Laravel aplikace do produkce málokdy znamená jedno poslední kliknutí. Je to okamžik, kdy na sobě začnou záviset kód, konfigurace, data, background procesy, storage, monitoring i plán návratu zpět. Během vývoje se dá drobná chyba často opravit rychle. V produkci může stejná chyba zasáhnout reálné uživatele a vytvořit tlak v nejhorší možnou chvíli.

Checklist před spuštěním používám rád, ale neberu ho jako mechanický seznam políček. Užitečnější je jako strukturovaná kontrola: způsob, jak na chvíli zpomalit, podívat se na aplikaci zvenku a ověřit, že bude provozovatelná i poté, co opustí lokální vývojové prostředí.

Produkční základ

První otázka je jednoduchá: je aplikace opravdu nastavená jako produkční aplikace? To znamená APP_ENV=production, APP_DEBUG=false, stabilní APP_KEY a produkční hodnoty pro doménu, databázi, cache, fronty, sessions, mail i filesystem. Zároveň to znamená, že secrets jsou mimo repozitář a hodnoty specifické pro prostředí nejsou jen ledabyle zkopírované z lokálního .env souboru.

Zní to jako základ, ale právě tahle část zachytí velkou skupinu skutečných problémů. Špatný mail sender, chybějící trusted proxies, nesprávné CORS, lokální queue driver nebo staging webhook secret mohou rozbít produkci i u kódu, který je jinak v pořádku.

U typického Laravel projektu před spuštěním explicitně procházím hlavně tyhle hodnoty:

• APP_ENV, APP_DEBUG, APP_URL, APP_KEY.

• Databázový host, název databáze, uživatele, heslo, charset a connection driver.

• Cache, session, queue, mail, filesystem, broadcast a logging driver.

• Trusted proxies, CORS, rate limits, cookie domain, secure cookies a webhook secrets.

• Externí API klíče, platební credentials, storage credentials a notifikační kanály.

Praktická deployment sekvence

Konkrétní deployment proces závisí na serveru a nástrojích, ale pořadí kroků by mělo být záměrné. Deployment script nemá být sbírka příkazů zkopírovaných ze starých projektů. Má popisovat, jak se právě tahle aplikace dostane ze stavu v repozitáři do zdravého produkčního releasu.

Menší Laravel deployment často vypadá nějak takto:

• Stáhnout nebo nahrát nový release a nainstalovat PHP závislosti přes composer install --no-dev --optimize-autoloader.

• Nainstalovat a sestavit frontend assets produkčními příkazy jako npm ci a npm run build.

• Přepnout aplikaci do maintenance mode, pokud to deployment potřebuje, hlavně u rizikovějších migrací.

• Spustit php artisan migrate --force až ve chvíli, kdy je jasný databázový plán a existují zálohy.

• Znovu vytvořit Laravel cache přes config:cache, route:cache, view:cache nebo event:cache, pokud dávají v projektu smysl.

• Restartovat PHP-FPM, queue workery, Horizon, Octane nebo jiný long-running proces, který drží starý kód v paměti.

• Vrátit aplikaci online a spustit krátký smoke test proti skutečným produkčním routám.

Důležité není slepě spustit všechny optimalizační příkazy. Důležité je rozumět tomu, v jakém stavu bude nasazená aplikace běžet. Stará route cache, staré compiled views nebo konfigurace z jiného releasu se hledají hůř než rozbitý build, protože aplikace může pořád nastartovat.

Databázové změny potřebují vlastní pozornost

Databáze si zaslouží pomalejší kontrolu než většina ostatních částí deploye. Kód se často dá vrátit rychle. Migrace, která změní produkční data, zamkne velkou tabulku nebo příliš brzy odstraní sloupec, se vrací mnohem hůř.

Před spuštěním migrací chci znát odpovědi na konkrétní otázky. Migrace jen přidává nové struktury, nebo mění existující data? Dotkne se velké tabulky? Přidává index, který může zamknout zápisy? Zůstane aplikace kompatibilní, pokud se starý a nový kód během deploye krátce překryjí? Existuje aktuální záloha a byl restore testovaný dost nedávno na to, abychom mu věřili?

U větších aplikací dávám přednost dvoukrokovým migracím. Nejdřív přidat nové struktury kompatibilně se starým kódem, nasadit aplikační kód, který umí číst a zapisovat oba tvary dat, a staré struktury odstranit až později. Tím se vyhnete jedné velké nevratné změně a rollback zůstane realističtější.

Fronty a plánovaná práce

Laravel aplikace často dělá důležitou práci mimo request lifecycle. E-maily, importy, exporty, notifikace, webhooky a synchronizace mohou záviset na queue workerech nebo scheduled tasks. Kontrola homepage po deployi nedokazuje, že funguje cokoliv z toho.

V produkci musí queue worker běžet pod správným process managerem, restartovat se po deployi, ukládat failed jobs a mít jasné retry a timeout chování. Scheduler by měl volat Laravel každou minutu a dlouhé joby by neměly donekonečna opakovat stejnou chybu. Pokud lokální prostředí používá sync driver, zaslouží si to zvláštní pozornost, protože může schovat problémy, které se projeví až při skutečném asynchronním zpracování.

Po deployi chci vědět, že workery běží nad novým kódem, ne nad předchozím releasem. Podle projektu to může znamenat php artisan queue:restart, restart Supervisor nebo systemd jednotek, případně kontrolu Laravel Horizon. Krátce po deployi také kontroluji failed jobs, protože právě fronty často jako první ukážou, že je špatně nastavená integrace třetí strany, storage disk, mail konfigurace nebo oprávnění.

Storage a veřejné soubory

Soubory často odhalí rozdíl mezi lokálním vývojem a produkcí. Lokální upload do storage/app může fungovat bez práce, zatímco produkce potřebuje S3, CDN, storage symlink, správná oprávnění adresářů nebo rozdílná pravidla pro public a private URL.

Před spuštěním ověřuji, že uploady jdou vytvořit, zobrazit, smazat a zahrnout do záloh. Pokud se používá lokální public storage, musí být součástí setupu php artisan storage:link. Pokud se používá vzdálený disk, credentials, region, bucket, visibility a generované URL musí odpovídat finální doméně.

Chování souborů se vyplatí testovat přes aplikaci, ne jen čtením konfigurace. Nahrajte jeden reprezentativní obrázek nebo dokument, zobrazte ho přes veřejnou stránku, stáhněte ho, pokud aplikace podporuje download, a smažte ho, pokud je mazání součástí workflow. Tím se problémy s oprávněním a URL projeví dřív.

Logy, monitoring a viditelnost chyb

Produkční aplikace by měla umět vysvětlit, co se v ní děje. Nestačí chyby skrýt před uživatelem. Tým potřebuje vědět, kam odcházejí výjimky, kdo dostane alerty, jak se rotují logy a jestli kritické business akce zanechávají dostatečný auditní záznam.

Tohle dává smysl i u menších projektů. Je velký rozdíl mezi tím, jestli problém odhalí monitoring, nebo naštvaný uživatel. Základní health check, čitelné logy, exception tracking a bezpečné chybové stránky dělají z produkčních problémů diagnostikovatelné události místo hádání.

Minimálně chci, aby chyby byly viditelné někde mimo lokální filesystem serveru. Log file na jednom stroji je lepší než nic, ale není to monitoring strategie. Aplikace by měla usnadnit odpověď na otázky: kdy chyba začala, jak často se děje, který release ji přinesl a kterého uživatele nebo workflow se dotkla?

Bezpečnost před spuštěním

Bezpečnost není jedna položka checklistu, ale Laravel launch má několik praktických oblastí, které se vyplatí zkontrolovat pokaždé: HTTPS, cookies, autentizaci, autorizaci, rate limiting, zranitelnosti závislostí, veřejné endpointy a ověřování webhooků.

Zvláštní pozornost věnuji administraci a dalším citlivým akcím. Nestačí, že stránka není vidět v menu. Přístup musí být vynucený autentizací a autorizací. Veřejné formuláře, login endpointy a API by měly mít rozumný rate limiting a externí callbacky by měly ověřovat podpis, token nebo jiný důvěryhodný mechanismus.

Do téhle kontroly patří i rizika závislostí. Před spuštěním dává smysl zkontrolovat, jestli Composer nebo npm balíčky neobsahují známé kritické zranitelnosti, jestli nejsou v produkci dostupné staré debug balíčky a jestli tam nejsou instalované nebo přístupné vývojové nástroje.

Zálohy a rollback

Deployment plán není kompletní, dokud neodpoví na otázku, co se stane, když release selže. Rollback plán nemusí být složitý, ale musí být konkrétní: kde je předchozí release, jak se obnoví kód, co se stane s migracemi, jak se řeší cache a workery a kdo rozhodne o návratu zpět.

Zálohy patří do stejné debaty. Nestačí je vytvářet; je potřeba je testovat. Pokud aplikace ukládá nahrané soubory, musí být zahrnuté také. Databázová záloha bez odpovídajících souborů nemusí stačit k obnovení skutečného stavu aplikace.

Rollback si rád představuji přes konkrétní scénáře. Co se stane, když build selže ještě před aktivací releasu? Co když migrace selžou v půlce? Co když aplikace vrací HTTP 200, ale padají queue joby? Co když platební brána nebo mail provider začne odmítat requesty? Každý scénář by měl mít jasného vlastníka a praktický další krok.

Finální kontrola po deployi

Po deployi je odpověď HTTP 200 jen začátek. Finální kontrola by měla projít flow, která jsou pro aplikaci důležitá: přihlášení, administraci, formuláře, e-maily, upload souborů, background joby a veřejné stránky. U e-shopu to může být testovací objednávka. U SaaS registrace a billing. U obsahového webu publikování a náhled obsahu.

Jednoduchý smoke test může být krátký a pořád užitečný. Otevřít homepage, přihlásit se, otevřít administraci, odeslat veřejný formulář, vyvolat jeden e-mail, nahrát jeden soubor, spustit nebo zkontrolovat jeden queue job, ověřit scheduler a podívat se do monitoringu, jestli nepřibyly nové výjimky. Test má být dost malý na to, aby se dal spustit po každém deployi, ne tak velký, že se mu tým začne vyhýbat.

Nejlepší checklist se mění v čase. Kdykoliv se při deployi objeví problém, stojí za to doplnit kontrolu, která by ho příště zachytila dřív. Takhle se z produkčního nasazení postupně stává méně stresová událost a víc opakovatelný proces.

Krátký checklist pro Laravel deployment

• Produkční hodnoty prostředí a secrets jsou správně.

• Závislosti, frontend assets a Laravel cache odpovídají releasu.

• Migrace jsou zkontrolované, zálohované a bezpečné pro reálná data.

• Fronty, workery, scheduler, storage a uploady fungují po deployi.

• Logy, monitoring, health checks, bezpečnostní základ a rollback kroky jsou připravené.

• Smoke test prochází nejdůležitější uživatelská flow.