Při růstu codebase se vyplatí měřit dobu běhu a míru selhání. Pokud jednotkové testy trvají déle než několik sekund, něco je špatně. Pokud integrační testy padají na náhodných chybách, je problém v izolaci nebo v prostředí. Sledujte, které testy nejčastěji padají a proč, a opravujte příčinu, ne test. Nakonec platí, že hranice mezi jednotkovými a integračními testy není dogmatická, ale musí být jasná a dodržovaná. Když ji tým zná a respektuje, růst kódu přestane být noční můrou.

Prvním krokem je zmapovat, co databáze skutečně obsahuje. V MySQL často zůstávají tabulky bez primárního klíče, sloupce s implicitními hodnotami, uložené procedury a triggery v proprietární syntaxi. Všechny tyto objekty je nutné projít ručně. Automatické konvertory sice převedou většinu DDL, ale výrazy specifické pro MySQL zůstanou nepřeložené nebo se přeloží špatně. Výsledkem bývá schéma, které se sice vytvoří, ale neodpovídá původní logice.

Automatizované testy se vyplatí pro opakující se scénáře: přihlášení, vyplnění formuláře, ověření výpočtu, kontrola notifikace. Napište je tak, aby byly nezávislé na datech a aby každý test začínal v čistém stavu. Pokud test závisí na předchozím, jeho pád zamaskuje skutečnou příčinu. Častá chyba je automatizovat vše, včetně vizuálních detailů, které se mění s každou aktualizací rozhraní. Takové testy pak padají kvůli posunutému pixelu, ne kvůli chybě v logice.

Další pastí je citlivost na velikost písmen. PostgreSQL převádí neuzavřené identifikátory na malá písmena, kdežto MySQL je na některých platformách nerozlišuje vůbec. Dotazy, které dřív fungovaly, mohou po migraci selhat na neexistující tabulku. Stejně tak LIMIT, OFFSET nebo implicitní přetypování řetězců na čísla se chovají odlišně. Aplikační vrstvu je proto nutné projít a otestovat, ne jen přenést schéma.

Jak vazbu sbírat, aby nezůstala jen u dvou mluvčí

Každý odhad vývojového úkolu vypadá na papíře čistě: napsat kód, otestovat, nasadit. Jenže skutečný čas zmizí jinde – v poradách, ve čtení cizího kódu, v čekání na odpověď, v opravách něčeho, co se rozbilo mimo zadání. Pokud tyto skryté činnosti nezahrneš, odhad bude vždycky krátký. Nejde o to přidat paušální procento. Jde o to pojmenovat, co se v úkolu skutečně skrývá, a přiřadit tomu čas ještě před tím, než slíbíš termín.

Pro začátek tedy stačí málo: popsat současný tok změny, vybrat jednu aplikaci, zautomatizovat cestu do produkce, zavést měření a domluvit se na společné odpovědnosti. Zbytek je postupné zlepšování, které nikdy nekončí. Kdo slibuje, že DevOps nasadí za týden a hotovo, buď lže, nebo nepochopil, že jde o způsob práce, ne o projekt s koncem.

Na co si dát pozor u datových typů a dotazů Zásadní rozdíl je v datových typech. MySQL je tolerantnější: například INT bez znaménka, TINYINT jako boolean nebo ENUM se v PostgreSQL chovají jinak. Datum 0000-00-00, které MySQL běžně přijme, PostgreSQL odmítne. Podobně řetězce s neplatnými znaky nebo prázdné hodnoty v číselných sloupcích. Před migrací je proto nutné data vyčistit a ověřit, že každý sloupec odpovídá cílovému typu. Nejedná se o formalitu – neplatná hodnota zastaví import celé tabulky.

Posledním krokem je zkušební provoz s reálnou zátěží. Sledujte dobu odezvy dotazů, plány provádění a chování transakcí. Teprve když aplikace i data projdou kontrolou, odpojte původní databázi. Většina problémů se totiž neprojeví při importu, ale až při prvním ostrém dotazu.

Migrace z MySQL do PostgreSQL vypadá na první pohled jako převod tabulek a přenos dat. Většina selhání ale nevznikne kvůli samotnému přenosu, nýbrž kvůli rozdílnému chování obou systémů, které se naplno projeví až po nasazení do provozu. Pokud se na tyto odlišnosti nepřipravíte předem, aplikace začne vracet chyby nebo tiše vracet jiné výsledky než dřív.

Před samotným přenosem si připravte testovací prostředí se stejnou verzí PostgreSQL, jakou plánujete v provozu. Data exportujte po částech, ne jedním velkým souborem, a průběžně kontrolujte počty řádků a kontrolní součty u klíčových tabulek. Po importu ověřte cizí klíče, indexy a sekvence – u sekvencí je častou chybou, že začínají od jedné a kolidují s už vloženými hodnotami. Teprve potom spouštějte aplikaci.