Jak začít s DevOps: praktický průvodce pro začátečníky

Verzování kódu často začíná jako jednoduchá záležitost: commit, tag, release. Jakmile ale projekt začne používat více knihoven, které se vyvíjejí vlastním tempem, přestává stačit intuitivní přístup. Než se pustíte do samotné implementace, je nutné si ujasnit, jaké úrovně verzí vlastně potřebujete. Máte interní knihovny, které sdílíte mezi týmy, a zároveň externí závislosti? Pro každou úroveň pak platí jiná pravidla. Klíčové je oddělit verzi aplikace od verzí jednotlivých knihoven – jinak se brzy ztratíte v tom, která kombinace vlastně produkuje funkční celek.

Při psaní testu si dejte pozor na použití ostrých dat z produkce. Test by měl být vždy nezávislý na okolním prostředí. Pokud test používá datum a čas, nezadávejte aktuální hodnotu, ale pevně zvolenou konstantu. Stejně tak se vyhněte náhodným hodnotám, které test dělají nestabilním. Test, který občas selže, pozbývá smyslu. Pro první test zvolte natvrdo zadaná data, abyste měli jistotu, že výsledek je vždy stejný.

Častý omyl je začít s nasazováním do produkce příliš brzy. Nejdřív si osvojte postupy na menších projektech nebo v odděleném prostředí. Zaveďte si pravidlo: změna musí projít automatickými testy, nasazením do stagingu a kontrolou metriku, než se dostane k uživatelům. To vyžaduje disciplínu, ale dlouhodobě vám ušetří víc času, než kolik do toho vložíte.

Kdy REST přestává stačit a přichází GraphQL Problém RESTu nastává, když máte složité datové vztahy (např. sociální síť) nebo když různí klienti potřebují různé části dat – mobilní aplikace chce jen id a název, web chce i popis a obrázky. Tehdy buď posíláte zbytečně velké payloady, nebo vytváříte mnoho endpointů. GraphQL tento problém řeší tím, že umožňuje klientovi specifikovat přesně, jaká data potřebuje. Jediný dotaz může sloučit data z více zdrojů, což eliminuje „over-fetching" i „under-fetching".

Jak strukturovat první test Každý test by měl mít tři části: přípravu, akci a ověření. V přípravě vytvoříte vstupní data, v akci zavoláte testovanou metodu a v ověření porovnáte výsledek s očekávanou hodnotou. Tuto strukturu dodržujte i u prvního testu, i když se vám zdá jednoduchá. Příklad: funkce pro sčítání dvou čísel. Příprava: čísla 2 a 3. Akce: zavolání funkce s těmito argumenty. Ověření: výsledek je 5. Nic víc, nic míň.

Když test napíšete, spusťte ho. Pokud projde, zkuste ho schválně rozbít změnou očekávané hodnoty. Tím si ověříte, že test skutečně funguje a není jen formální. Poté hodnotu vraťte zpět. Tento postup je dobré si zapamatovat, protože odhaluje falešně zelené testy, které testují špatnou věc. Jakmile máte první test hotový, pokračujte dalším. Postupně získáte jistotu a testování se stane přirozenou součástí vašeho vývoje.

Na závěr: DevOps není o tom, že budete používat „všechno moderní". Začněte s jedním týmem a jedním projektem, kde vidíte největší bolest. Zapojte lidi z obou stran – vývoje i provozu – a pravidelně vyhodnocujte, jestli se situace zlepšuje. Postupně rozšiřujte osvědčené postupy na další služby. Klíčem není rychlost, ale konzistence a schopnost učit se z vlastních chyb.

Pro samotnou správu závislostí používejte nástroj, který umožňuje uzamčení přesných verzí, nejen rozsahů. Vždy verzujte soubor se závislostmi, ať už se jedná o manifest nebo lockfile. Tento soubor by měl být součástí každého commitu, aby byla reprodukovatelnost buildů zaručena. Při aktualizaci knihovny pak postupujte podle principu nejmenšího kroku: nejprve aktualizujte opravné verze, otestujte, pak vedlejší a nakonec hlavní. Pamatujte, že aktualizace hlavní verze často znamená změnu chování, ne jen nové API. Proto si před takovým krokem vždy načtěte changelog a porovnejte rozdíly mezi verzemi.

Postman je jedním z nejrozšířenějších nástrojů pro testování a dokumentaci API. Naučit se s ním pracovat vyžaduje více než jen odeslat pár požadavků – jde o systematický přístup, který vám ušetří hodiny ladění. Následující postupy vycházejí z reálné praxe a zaměřují se na konkrétní činnosti, které využijete při každodenní práci s rozhraními.

Častou chybou je ignorování rozdílu mezi formátem dat. Vždy si ověřte, zda API očekává JSON, XML nebo urlencoded data. V Postmanu zvolte správný typ v záložce Body – nejběžnější je „raw" s typem JSON. Při posílání souborů použijte „form-data". Dále si dejte pozor na kódování českých znaků, které může způsobit chybnou serializaci. Nastavte v hlavičkách Content-Type: application/json; charset=utf-8, abyste předešli neočekávaným výsledkům.

Praktické doporučení: použijte REST, když je vaše API jednoduché, málo se mění a hlavním konzumentem je webový prohlížeč. GraphQL volte tehdy, když máte heterogenní klienty (mobil, desktop, IoT), potřebujete agregovat data z mikroservis nebo chcete minimalizovat přenos dat u pomalých mobilních sítí. Častou chybou je kombinovat obojí v jednom projektu bez jasného pravidla – pak ztrácíte výhody obou.