Migrace starších PHP stránek bez narušení obchodních operací

V DigiForge jsme viděli příliš mnoho projektů migrace legacy PHP, které se zvrtly – ne proto, že by technologie byla složitá, ale proto, že byznys během přesunu běžel dál. Samotné slovo „migrace“ pochází z latiny a znamená přesun z jednoho místa na druhé; v informatice pak konkrétně „začít používat nový počítačový systém nebo přesouvat informace z jednoho typu systému na jiný“ [1]. To zní přímočaře, ale když migrujete PHP monolit, který zpracovává objednávky, uživatelské session a platební integrace, skutečnou výzvou je zajistit, aby si vaši zákazníci ničeho nevšimli.

Než se dotknete jediného řádku kódu, proveďte analýzu

Než vůbec začneme uvažovat o psaní nových routerů nebo instalaci moderního frameworku, provedeme audit stávající aplikace – nejen jejího kódu, ale i jejího chování za běhu. Začněte důkladnou inventurou všech vstupních bodů: každá routa, každý cron job, každá úloha ve frontě. Legacy PHP aplikace často obsahují skryté koncové body – třeba cron.php, který každou neděli spouští výplaty, nebo vlastní API endpoint používaný externí přepravní službou. Pokud nějaký přehlédnete, migrace něco rozbije.

Během auditu také zdokumentujte datový tok: jak se stará aplikace připojuje k databázi? Jsou použity uložené procedury? Existuje sdílený souborový systém pro nahrané obrázky nebo session soubory? Mnoho legacy PHP aplikací spoléhá na souborové session, které se neškálují horizontálně. To je varovný signál, který řešíme brzy – často migrací session do Redis nebo databáze.

Zvolte migrační strategii, která odpovídá vaší toleranci k riziku

V DigiForge obvykle doporučujeme jednu ze tří strategií podle toho, jaké riziko je firma ochotna podstoupit.

Velký třesk – přepis od základů

Toto je nejdramatičtější varianta: postavíte nový systém od nuly a pak na něj najednou přepnete. Je to také nejrizikovější. Viděli jsme, že funguje jen tehdy, když je stará aplikace malá (řekněme pár desítek stránek) nebo když si firma může dovolit plánované odstávky. U čehokoli s transakcemi v reálném čase nebo zákazníky 24/7 se tomuto přístupu vyhněte.

Vzor škrtícího fíkovníku

Tento vzor, pojmenovaný podle tropické rostliny, která postupně obaluje svého hostitele, umožňuje nahrazovat části starší aplikace postupně. Konkrétní URL nebo API endpointy směrujete na nový kód, zatímco zbytek stále běží na starém PHP. Load balancer nebo reverzní proxy (např. Nginx nebo HAProxy) může směrovat provoz na základě cesty požadavku. Každá nahrazená část snižuje riziko, protože najednou měníte jen malou plochu. Tento vzor používáme téměř u každé velké migrace.

Feature Flags všude

I při použití fíkovníku škrtiče poskytují feature flags možnost okamžitého vypnutí. Pokud nový checkout endpoint vyhazuje chyby, přepnete flag a provoz se vrátí ke starému kódu – a to vše bez nasazení. Dobře fungují nástroje jako LaunchDarkly nebo jednoduchý přepínač uložený v databázi. Všechno kódujeme za flagem, dokonce i připojení k databázi. Díky tomu můžeme otestovat nový dotaz v produkci jen s několika uživateli, než ho nasadíme všem.

Proveďte migraci s nulovým výpadkem

Nulový výpadek neznamená nulové riziko – znamená, že uživatel nikdy neuvidí chybovou stránku. Klíčem je duální zápis: když přecházíte na nové schéma databáze nebo jiné úložiště, zapisujte data současně do starého i nového systému. Začněte zápisem do obou, čtením ze starého. Jakmile se nový systém dotáhne a ověříte integritu dat, přepněte čtení na nový systém. Nakonec zastavte zápis do starého systému. Tento postup funguje pro databáze, fronty, souborová úložiště i API integrace.

<?php
// Example: dual-write to old and new databases
$legacyDb = getLegacyConnection();
$newDb = getNewConnection();

function saveOrder($orderData) {
    global $legacyDb, $newDb;
    // Write to both
    $legacyDb->insert('orders', $orderData);
    $newDb->insert('orders', $orderData);
}

// Read from legacy until we verify new data
function getOrder($orderId) {
    global $legacyDb;
    return $legacyDb->fetchOne('SELECT * FROM orders WHERE id = ?', [$orderId]);
}

Během fáze duálního zápisu spouštíte každých pár minut reconciliační skripty, které porovnávají obě úložiště. Jakákoli odchylka je rychle odhalena. Jakmile nový systém vykazuje shodu po celý jeden obchodní cyklus (obvykle 48 hodin), přepnete čtení. Následující hodinu pečlivě sledujte chybové logy – pokud by cokoli vypadalo podezřele, vraťte se zpět.

Správa stavu relace

Starší PHP často používá $_SESSION ukládaný do souborů. Nová aplikace v Laravelu nebo Symfony pravděpodobně očekává databázové nebo Redis relace. Aby uživatelé zůstali během migrace přihlášeni, implementujeme most pro relace: stará aplikace zapisuje relace jak do souborů, tak do sdíleného Redis úložiště; nová aplikace čte z Redis. Po dokončení migrace vypnete zápis do souborů a odstraníte starý handler relací.

Validace po migraci a plánování rollbacku

I při pečlivém plánování se něco pokazí. To není pesimismus – to je inženýrský realismus. Než přepnete finální přepínač, napište plán návratu, který zahrnuje obnovení DNS záznamů, vrácení změn schématu databáze a spuštění staré aplikace ze snapshotu. Nacvičte si rollback alespoň jednou v stagingu.

V DigiForge vždy necháváme staré produkční prostředí běžet alespoň dva týdny po velké migraci. Náklady na pár serverů navíc jsou zanedbatelné ve srovnání s náklady na neúspěšný rollback, který trvá hodiny.

Validace nespočívá jen v kontrole, zda se stránky načítají. Spouštíme automatické testy obchodních transakcí: zadání objednávky, aktualizace profilu, zpracování vrácení peněz. Porovnejte výstup kritických API endpointů mezi starým a novým systémem. Pokud používáte monitorovací nástroj jako New Relic nebo Sentry, nastavte vlastní upozornění na jakékoli 5xx chyby nebo pomalé dotazy. Nakonec zapojte obchodní tým – nechte je spustit jejich denní workflow na novém systému ve stagingu před ostrým spuštěním.

Časté nástrahy a jak se jim vyhýbáme

• Předpoklad, že starý kód je správný. Starší PHP často obsahuje tiché chyby, které se staly „funkcemi“. Opakovat každé chování? Někdy je bezpečnější opravit chybu v nové verzi, pokud s tím obchod souhlasí.
• Zapomínání na cron úlohy a plánované úkoly. Ty staré curl volání na vlastní skript? Potřebují domov v novém systému. Migrujeme cron úlohy do plánovače úloh, jako je Laravel scheduler nebo dedikovaný worker.
• Zanedbání integrací třetích stran. Platební brány, API pro dopravu a webhooky partnerů posílají data v konkrétních formátech. Testujte integrační endpointy brzy – nechcete objevit neshodu formátů na Černý pátek.

Další ponaučení: nedůvěřujte staré dokumentaci. Zdroj pravdy je kód. Vždy provádíme důkladnou analýzu kódu s vývojářem, který původní systém napsal (pokud je k dispozici), nebo s členem týmu, který ho udržoval roky. Jejich mentální model zvláštností aplikace je k nezaplacení.

Závěr

Migrace starého PHP webu je jako provádět operaci srdce pacientovi, který zrovna běží maraton. Riziko je reálné, ale odměna – moderní výkon, bezpečnost a produktivita vývojářů – je obrovská. Ve DigiForge jsme provedli desítky firem tímto procesem. Klíčem je postupovat v malých, vratných krocích, vždy nechat starý systém běžet a nepřestat monitorovat, dokud si nejste jisti, že nový systém je stabilní.

Pamatujte: migrace není jen o technologii – jde o to udržet vaše podnikání v chodu, zatímco měníte motor za letu. Plánujte pečlivě, testujte neúnavně a vždy mějte připravený rollback. Vaši uživatelé nikdy nepoznají, že se něco změnilo.