DevOps, o kterém většina začátečníků zakopne
Prakticky začněte exportem dat. Použijte nástroje, které umí zapsat data do formátu SQL nebo CSV. U CSV si dejte pozor na oddělovače, kódování a na to, jak jsou reprezentovány binární hodnoty. U SQL dumpu zase na to, zda exportujete strukturu a data odděleně. Před importem do PostgreSQL vypněte kontroly cizích klíčů a indexy – urychlíte tím nahrávání. Indexy a constrainty pak vytvořte až po dokončení importu.
Závěrem: migrace vyžaduje čas a testování, ale přináší výhody v podobě robustnějších funkcí, lepší práce s JSON a pokročilých indexů. Pokud se vyhnete nejčastějším chybám popsaným výše, přechod zvládnete bez ztráty dat a s minimálním výpadkem.
Začněte jednou službou, ne celým procesem Nejčastější chyba je pokusit se zautomatizovat všechno najednou. Místo toho si vyberte jednu malou aplikaci, která se nasazuje často, a proveďte ji celým řetězcem: sestavení, test, nasazení, monitoring. K tomu použijte skripty, které zvládnete spustit lokálně, a teprve pak je přeneste do CI. Cílem není dokonalá pipeline, ale rychlá zpětná vazba — pokud něco spadne, musíte to vědět do deseti minut.
Další past, do které se snadno spadnete, je testování vnitřních implementací. NUnit umožňuje testovat privátní metody přes reflexi, ale to je téměř vždy špatně. Testujte chování z pohledu volajícího, ne vnitřní mechanismy. Pokud potřebujete otestovat privátní logiku, znamená to, že je pravděpodobně příliš složitá a měla by být extrahována do samostatné třídy. V opačném případě budete psát křehké testy, které se rozbijí při každé změně implementace, a to i když se vnější chování nezmění. To vede k frustraci a k tomu, že testy začnete ignorovat.
Typickou chybou začátečníků je použití NoSQL pro data, která vyžadují vztahy a transakce. Pokud ukládáte faktury a položky faktur, potřebujete zaručit, že se buď uloží celý dokument, nebo se neuloží nic. Většina NoSQL databází sice nabízí transakce, ale jejich použití je často omezené a složitější než v SQL. Než začnete modelovat, ověřte si, jak daný systém řeší atomické operace. Další pastí je špatný výběr typu databáze: dokumentová databáze není vhodná pro grafy vztahů mezi uživateli, klíč-hodnota úložiště neumí efektivně dotazovat podle více atributů. Vždy si nejprve definujte, jak budete data číst, a teprve potom vyberte konkrétní nástroj.
Samotný import dat zkuste nejprve do prázdné databáze bez cizích klíčů. Pokud import spadne uprostřed, mějte možnost začít znovu – proto vždy pracujte s čerstvým schématem. Po dokončení importu zkontrolujte počty řádků v kritických tabulkách a porovnejte je s původní databází. Pro větší objemy dat se vyplatí rozdělit import na menší dávky, které lze snadno opakovat.
DevOps není nástroj, který koupíte, ani tým, který založíte. Je to způsob, jakým spolu mluví vývoj a provoz. V praxi to znamená, že vývojář neshazuje kód přes plot a provozář nečeká, až něco exploduje. Pokud začínáte, nejdřív zjistěte, kde se vaše firma zasekává — jestli při nasazování, testování nebo sledování chyb. Bez mapy problému totiž každá automatizace jenom zrychlí zmatek.
Typickou chybou je přímý přepis SQL dotazů. V PostgreSQL nefunguje LIMIT s čárkou jako v MySQL – musíte použít klauzuli OFFSET. Dále se liší funkce pro práci s řetězci a datem, např. DATE_FORMAT nemá přímou obdobu, používá se TO_CHAR. Pokud ve svých dotazech používáte backticks pro označení sloupců, v PostgreSQL je nahraďte uvozovkami a dbejte na malá a velká písmena, protože PostgreSQL rozlišuje citlivost identifikátorů.
Když začnete psát jednotkové testy v C# s NUnit, první věc, kterou objevíte, je, že samotné psaní testů není to nejtěžší. Největší úskalí přichází ve chvíli, kdy se testy začnou navzájem ovlivňovat a vy ztrácíte přehled o tom, co vlastně testujete. Typická chyba začátečníků? Sdílení stavu mezi testy. Pokud použijete statickou proměnnou, která se mění v jednom testu a ovlivní výsledek druhého, přestanou být testy izolované. A izolace je základní princip, bez kterého se jednotkové testy mění v noční můru.
Shrňme si to: NoSQL je výkonný nástroj, ale jeho použití má smysl pouze tehdy, když rozumíte jeho omezením. Nevybírejte ho podle popularity, ale podle konkrétních požadavků na škálování, flexibilitu schématu a rychlost vývoje. Pokud váháte, zkuste nejprve prototyp s malým objemem dat a otestujte, jak vám vyhovuje modelování bez pevných tabulek. Často zjistíte, že SQL vám postačí a NoSQL přidá jen zbytečnou složitost. A pokud se rozhodnete pro NoSQL, investujte čas do studia jeho specifik – ušetříte si tím později spoustu bolesti při ladění výkonu.