Jetstack
Zpět na blog Blog

Správa verzí — body obnovy konfigurace a cesta zpět

Publikováno 1. října 2025

Technická ilustrace k článku Jetstacku

Implementace je živá práce s konfigurací. Přidáte datový typ, upravíte pohled, zapojíte automatizaci, doladíte oprávnění – a platforma přitom mění svou podobu. Většina těch změn je k lepšímu, ale čas od času se některá ukáže jako omyl a vy potřebujete cestu zpět k tomu, jak věci vypadaly předtím. Přesně to nabízí správa verzí: pojmenované body obnovy vaší konfigurace, které si uložíte ve vhodnou chvíli, a pokud se pozdější změna nepovede, můžete se k nim vrátit.

Verze je bod obnovy. Když ji publikujete, stanou se dvě věci najednou. Zapíše se srozumitelný záznam do přehledu vydání – kód verze, poznámky k vydání a interní poznámky určené jen pro operátory – a zároveň se pořídí snímek konfigurace platformy v daném okamžiku spolu se záznamem o struktuře databáze. Protože publikovaná verze nese skutečný stav konfigurace, a ne jen její název, je to místo, kam se můžete vrátit.

Verze zachytí vaši konfiguraci. Snímek pokrývá tutéž oblast, která se mezi prostředími přenáší při synchronizaci: datové typy a jejich vlastnosti (včetně vlastních vlastností přidaných k systémovým typům, jako je uživatel), moduly, pohledy a dotazy, role, skupiny, kořeny a oprávnění, automatizace, stránky Canvas, e-mailové šablony a definice plánovače, konektory, aplikace a MCP servery, právní důvody a účely i překlady konfigurace. Konfigurací jsou i seznamy položek číselníků, takže se ukládají také. Ke všemu si verze uchová otisk struktury databáze – které tabulky a sloupce v okamžiku publikace existovaly –, díky čemuž vám pozdější vrácení dokáže přesně říct, o co byste přišli.

Zachytává konfiguraci, ne data. Některé věci zůstávají záměrně stranou: transakční záznamy, které vytvářejí vaši uživatelé (projekty, úkoly, objednávky), samotné uživatelské účty (typ „uživatel“ a jeho vlastní vlastnosti se uloží, jednotlivé řádky ne), nahrané soubory a citlivé údaje – přihlašovací údaje konektorů se ze snímku odstraňují. Představa je jednoduchá: verze si pamatuje, jak je platforma utvářená, ne co je uvnitř.

Bod obnovy publikujete na obrazovce Verze. Jakmile zadáte kód verze a poznámky, snímek se pořizuje na pozadí – u velkého prostředí to chvíli trvá –, takže nová verze nejdřív projde stavem „pořizuje se“ a teprve pak je „pořízena“ a použitelná jako cíl pro vrácení. Verze, které jste publikovali dřív, než tato možnost existovala, zůstávají platnými záznamy v přehledu vydání, ale nemají žádný bod obnovy a vrátit se k nim nelze.

Vrácení obnoví vaši aktuální konfiguraci do zvoleného bodu obnovy a výsledek publikuje jako novou verzi. Je to dopředná operace, ne tajné přetáčení historie: platforma spočítá opačné změny, provede je a zapíše jako další záznam v přehledu. Historie verzí tak zůstává poctivá a lineární.

Náhled vrácení vám ukáže přesně, co se stane, ještě než se cokoli změní. Má tři části: co se znovu použije (konfigurace z bodu obnovy, která se znovu vytvoří nebo upraví), co se smaže (konfigurace, kterou jste přidali po bodu obnovy a kterou vrácení odstraní – a smazání datového typu zahodí i jeho tabulku) a fyzické změny v databázi (konkrétní tabulky a sloupce, které vrácení zahodí, odvozené z uloženého otisku struktury). Seznam mazání si pečlivě přečtěte; právě tam hrozí ztráta dat.

Vrácení obnoví strukturu, ne data – to je ta nejdůležitější věc, kterou je potřeba říct všem zúčastněným. Datový typ nebo vlastnost, které jste od bodu obnovy přidali, se odstraní a s nimi i jejich data. Datový typ nebo vlastnost, které jste od bodu obnovy smazali, se znovu vytvoří, ale vrátí se prázdné – jejich data byla ztracena už ve chvíli původního smazání. Vrácení není záloha: ztracené řádky obnovíte jen ze zálohy databáze. Navíc běží na pozadí a stejně jako každou živou změnu schématu ho nelze transakčně vzít zpět – když potřebujete vrácení zrušit, přejděte dopředu na jiný bod obnovy.

Přesné v jádru, u zbytku podle nejlepšího vědomí. Vrácení je přesné pro strukturální jádro konfigurace – datové typy, vlastnosti a hlavní objekty jako moduly, pohledy, dotazy, role, stránky Canvas a automatizace vytvořené po bodu obnovy se odstraní spolehlivě. U oprávnění, překladů, položek číselníků a u konektorů, aplikací a MCP serverů se hodnoty z bodu obnovy znovu použijí, ale to, co jste přidali navíc, se nemusí odstranit. A protože citlivé údaje nejsou nikdy součástí snímku, u vráceného konektoru může být potřeba znovu zadat přihlašovací údaje.

Odchylka konfigurace (drift) je poctivá odpověď na otázku „jaká verze právě běží?“. Verze, kterou prostředí hlásí přes API, je jeho poslední publikovaný bod obnovy – ne příslib, že se od té doby nic nezměnilo. Protože pracujete živě, konfigurace se téměř vždy od poslední publikované verze odchýlí dopředu. Aby to bylo vidět, platforma vedle publikované verze zveřejňuje otisk aktuální konfigurace; když se ty dva liší, konfigurace se od té verze posunula. Integrace, která potřebuje vědět, jestli je produkce přesně publikovanou verzí, může oba otisky porovnat.

Verzování je historie, ne větve. Verze tvoří lineární řadu bodů obnovy. Úpravy zůstávají živé – není tu žádná příprava, kde by změny čekaly nepublikované, ani paralelní větve ke slučování. Postup je přímočarý: pracujte živě, ve chvílích, kdy je konfigurace v ověřeném stavu, publikujte bod obnovy, a když je potřeba, vraťte se zpět. A když chcete ověřenou konfiguraci přenést mezi prostředími, a ne v čase zpět, je na to synchronizace prostředí.

Aby vám funkce opravdu posloužila, vyplatí se pár návyků. Bod obnovy publikujte dřív, než se pustíte do rizikové nebo rozsáhlé změny, ne až po ní – právě ten záchytný bod budete chtít, když se něco pokazí. Používejte srozumitelné a stálé kódy verzí a poznámky k vydání psané pro lidi, kteří prostředí spravují a provozují. Před potvrzením vrácení si v náhledu přečtěte část o mazání a o fyzických změnách. A na transakční data si udržujte skutečnou strategii zálohování databáze: vrácení obnoví podobu platformy, ne její obsah – každé chrání něco jiného.