Příručka popisuje zavedení agentního vývoje u plné instalace NET Genia: jak agentům nastavit přístup a pravidla, jak připravit vývojovou instanci a jak se změny aplikací dostávají do provozní instance. Doporučený postup, na který odkazují Všeobecné obchodní podmínky agentního vývoje v článku 5.3, popisují kapitoly 3 a 4.
1. Dva způsoby práce
Agent smí pracovat ve vývojové i v provozní instanci. Rozdíl je v tom, kde se změna aplikací připraví a kdy ji uvidí uživatelé:
| Způsob | Kde agent mění aplikace | Jak se změna dostane do provozu | Riziko |
| Přes vývojovou instanci (doporučený) | ve vývojové instanci | releasem, až když je změna ověřená | chyba agenta zůstane ve vývojové instanci |
| Přímo v provozní instanci | v provozní instanci | okamžitě | chyba agenta se projeví uživatelům a nese ji provozovatel instance |
Oba způsoby lze kombinovat – například rozsáhlejší úpravy připravovat ve vývojové instanci a drobné opravy dělat přímo v provozu. Pak ale platí pravidla z kapitoly Kombinace obou způsobů.
2. Přístup agentů
2.1. Vývojáři a osobní tokeny
- Agenta smí k instanci připojit jen uživatel s administrátorskými právy. Které administrátory MCP server přijme, určuje seznam Administrátoři s přístupem k MCP serveru v Nastavení NET Genia na záložce Oprávnění.
- Každý vývojář pracuje pod vlastním osobním tokenem – v každé instanci má nejvýše jeden. Token se nesdílí, nevpisuje do konfiguračních souborů, sdílených nástrojů ani automatizací a ukládá se do proměnné prostředí; každý zápis je tak přiřaditelný konkrétní osobě. Vygenerování a uložení tokenu popisuje příručka Připojení AI nástroje k MCP serveru.
- Oprávnění tokenu určují, co agent smí:
| Instance | Čtení všech dat a modelu přes MCP server | Zápis všech dat a modelu přes MCP server |
| Vývojová | ano | ano |
| Provozní | ano | při práci přes vývojovou instanci ne, nebo jen dočasně pro konkrétní zápis dat; při práci přímo v provozu ano |
- Platnost tokenu je 90 dnů. Token pracovníka, který odejde nebo změní pracovní zařazení, je potřeba bez odkladu smazat – uživatel „Administrator“ (ID 1) maže cizí tokeny na záložce MCP token v sekci Tokeny ostatních uživatelů.
- Pracuje-li agent s oběma instancemi, připojují se do AI nástroje jako dva servery. Jejich názvy se odvozují z adres instancí (například „portal-firma-cz“ a „portal-firma-cz-dev“), takže je agent i vývojář spolehlivě rozliší; pravidlo popisuje příručka Připojení AI nástroje k MCP serveru.
- Každý přístup agenta čerpá licenci současně přihlášeného uživatele stejně jako přihlášení vlastníka tokenu.
2.2. Pravidla pro agenta
Pravidla pro agenta jsou textové instrukce, které agent dostane na začátku každé práce – u Claude Code soubor „CLAUDE.md“, u Codexu soubor „AGENTS.md“ v adresáři, ze kterého se nástroj spouští, u agenta v Microsoft Copilot Studiu jeho pokyny. Agent jedná jen podle toho, co má zapsáno: co v pravidlech ani v modelu aplikací není, nahradí domněnkou. Pravidla proto musí existovat před prvním připojením agenta a určují alespoň:
- přes kterého AI poskytovatele a kterého klienta smějí data instance odejít,
- která instance je provozní a která vývojová (názvy serverů v AI nástroji) a co agent v provozní instanci smí – jen číst, zapisovat data, nebo měnit i aplikace,
- co agent nesmí udělat nikdy – typicky smazat editační formulář nebo databázový ovládací prvek, změnit název databázové tabulky nebo sloupce, zapisovat do provozní instance bez historie změn nebo mazat data bez výslovného potvrzení,
- které operace se nad provozní instancí nespouštějí vůbec nebo jen mimo provozní dobu – například čtení velkých tabulek a hromadné dávky,
- kdy se agent musí zeptat, jak pojmenovává nové aplikace, formuláře a ovládací prvky a co před potvrzením změny ověřuje.
Pravidla se průběžně doplňují: každá chyba agenta má skončit novým nebo upřesněným pravidlem. Nejistotu agenta je lepší vyřešit doplněním popisu do aplikace nebo do pravidel než dalším pokynem v konverzaci – pokyn platí jen pro jednu práci, pravidlo pro všechny další.
3. Doporučený postup – vývojová instance
3.1. Založení
- Vývojová instance je samostatná instalace NET Genia s kopií databáze provozní instance, která slouží výhradně ke zkoušení změn. Instalaci a přenos databáze, externích funkcí, tiskových šablon a souborových příloh popisuje příručka Vývojové prostředí.
- Vývojová instance potřebuje vlastní licenční klíč s povoleným agentním vývojem. K provozní instanci ho NetGenium pro jednu vývojovou instanci poskytuje bez dalšího poplatku.
- Obě instance se udržují na stejné verzi NET Genia – sloučení struktury mezi různými verzemi nelze provést.
- Vývojová instance nese provozní data, včetně osobních údajů, a agent je z ní odesílá k AI poskytovateli stejně jako z provozní instance. Zabezpečení vývojové instance a případná anonymizace dat jsou na provozovateli.
3.2. Postup obnovy
Postup, kterým se vývojová instance znovu naplní aktuálním stavem provozu, má být popsaný předem – kdo obnovu provádí, kdy a v jakých krocích. Základem je záloha provozní databáze a její obnova ve vývojové instanci programem „SqlBackup.exe“, podle potřeby doplněná o externí funkce, tiskové šablony a souborové přílohy; postup popisuje příručka Vývojové prostředí.
- Obnova přepíše všechno, co ve vývojové instanci vzniklo, včetně rozpracovaných změn aplikací. Provádí se proto po releasu, kdy jsou ověřené změny už v provozu, nebo s vědomím, že se rozpracovaná práce zahodí.
- Obnova přenese do vývojové instance i osobní MCP tokeny a seznam Administrátoři s přístupem k MCP serveru z provozní instance. Token vygenerovaný dříve ve vývojové instanci přestane platit a token z provozní instance začne platit i ve vývojové, se svými oprávněními. Vývojáři si proto po každé obnově ve vývojové instanci vygenerují token znovu a změní hodnotu proměnné prostředí, ve které ho mají uložený.
- Obnova přenese i Nastavení NET Genia provozní instance. Součástí postupu má být i to, co se ve vývojové instanci po obnově vypne nebo přenastaví, aby nekomunikovala s okolím jako provoz – typicky odesílání e-mailů a napojení na externí systémy.
3.3. Vývoj
- Agent pracuje v rytmu popsaném v příručce Agentní vývoj: změny aplikací zapisuje do vývojové instance přes MCP server a vývojář je ověří přímo v jejím portálu. Výstupy agenta jsou návrh, který je potřeba ověřit – tvrzení nedoložené dokumentací, modelem aplikací nebo daty instance je neověřené.
- Vývojář vede seznam změn připravovaného releasu – které aplikace, formuláře, ovládací prvky, nahlížecí stránky, skripty a dotazy se mění. Proti tomuto seznamu se před releasem kontroluje rozdíl mezi instancemi.
- Databázovou tabulku ani sloupec agent nepřejmenovává a nemaže bez rozhodnutí vývojáře. Sloučení struktury přejmenovaný sloupec v provozní instanci smaže a založí znovu, a jeho data se tím ztratí. Zobrazovaný název prvku se mění bez rizika – identifikátory zůstávají.
- Release přenáší strukturu, ne data. Data, která mají být i v provozu – typicky nové položky číselníků –, se v provozní instanci zapíšou samostatně: v editačním formuláři, nebo přes MCP server s historií změn.
- Programový kód (externí funkce, API) patří do správy zdrojového kódu; knihovna „ngef.dll“ se do provozní instance kopíruje v rámci releasu.
4. Release do provozní instance
Release přenese do provozní instance celou strukturu aplikací vývojové instance a data provozu zachová. Provádí se programem „SqlBackup.exe“ – exportem struktury ve vývojové instanci, zkušebním sloučením a sloučením v provozní instanci. Celý postup včetně posouzení kolizí popisuje příručka Vývojové prostředí.
4.1. Před releasem
- Porovnání s původním stavem. Agent přečte model aplikací obou instancí – v provozní instanci jen čtením – a vypíše rozdíly: přidané, změněné a odebrané aplikace, editační formuláře, ovládací prvky, nahlížecí stránky, skripty, dotazy a oprávnění. Vývojář rozdíly porovná se seznamem změn releasu. Rozdíl, který v seznamu není – rozpracovaná změna nebo změna provedená přímo v provozu –, se před releasem vyřeší.
- Zkušební sloučení („merge test“) porovnává jen strukturu databázových tabulek; skripty, dotazy a nahlížecí stránky neporovnává. Proto se před releasem provádějí obě kontroly.
4.2. Sloučení struktury
- Verze NET Genia se ve vývojové i provozní instanci sjednotí.
- Ve vývojové instanci se struktura vyexportuje programem „SqlBackup.exe“, profilem Database structure (merge).
- Provozní databáze se zazálohuje.
- V provozní instanci se spustí zkušební sloučení – profil Database structure (merge test) – a vývojář projde soubor „SqlBackup.htm“. Každé smazání sloupce, přejmenování a změnu datového typu musí umět zdůvodnit; bez toho se sloučení neprovádí.
- Provede se sloučení – profil Database structure (merge). Volba User settings from old version zachová uživatelům provozní instance jejich portlety, oblíbené položky a nastavení nahlížecích tabulek.
- Soubory mimo databázi – knihovna „ngef.dll“ a knihovny, které používá, a soubory v adresáři „Config“ – se do provozní instance zkopírují samostatně. Tiskové šablony nabídne „SqlBackup.exe“ převzít při sloučení.
Sloučení zachová data provozní instance, Nastavení NET Genia, povolené IP adresy, osobní MCP tokeny a členství uživatelů v uživatelských skupinách. Tabulky, které vývojová instance nemá, sloučení smaže – jejich data předtím uloží do adresáře „Temp“.
Podrobnosti
- Aktualizace aplikace ze souboru „nga“ jako release vhodná není: aplikaci nejdřív smaže a ze souboru ji vytvoří znovu, takže zruší odkazy z jiných aplikací a při chybě importu původní aplikace už neexistuje (viz Import a export aplikací).
4.3. Po releasu
- Agent čtením porovná model aplikací provozní instance s vývojovou – v rozsahu releasu se mají shodovat. Zbylé rozdíly se vysvětlí.
- Vývojová instance se obnoví z aktuální zálohy provozní databáze (viz Postup obnovy), aby další vývoj vycházel ze skutečného stavu provozu.
5. Práce přímo v provozní instanci
Agent smí data i aplikace měnit přímo v provozní instanci. Změna se uživatelům projeví okamžitě a bez ověření ve vývojové instanci, a za její následky odpovídá provozovatel instance. Riziko snižují tato opatření:
- Záloha před větší změnou. Předchozí verze skriptů, databázových dotazů a kódu prvků HTML a JavaScript agent přečte nástrojem „get_model_history“; předchozí podobu editačních formulářů, ovládacích prvků, nahlížecích stránek a oprávnění přes MCP server nezjistí. Před větší změnou je proto vhodné zazálohovat databázi. Smazání databázového ovládacího prvku nebo editačního formuláře smaže i jeho data a vrátit ho nelze.
- Zápis s historií změn. Agent zapisuje a maže data vždy s historií změn – zápis přes MCP server se ve výchozím stavu do historie změn nezaznamenává a historii je potřeba výslovně požadovat. Patří to do pravidel pro agenta.
- Historie změn se nevypíná. Editační formulář se zakázaným protokolováním historie záznamů historii nezapíše ani při zápisu s historií změn.
- Skripty formuláře se nespustí. Zápis dat přes MCP server nespouští skripty editačního formuláře – neproběhnou validace, přepočty ani notifikace. Data, na jejichž uložení taková logika navazuje, se zapisují v editačním formuláři (viz Integrovaný MCP server).
- Zátěž a provozní doba. Změnu aplikace, kterou uživatelé právě používají, a náročné operace je vhodné dělat mimo provozní dobu; které operace to jsou, určují pravidla pro agenta.
- Kontrola vývojářem. Vývojář si navrženou změnu nechá od agenta popsat dřív, než ji agent zapíše, a po zápisu ji ověří v portálu.
5.1. Kombinace obou způsobů
Má-li provozní instance i vývojovou instanci, ve které se připravují releasy, platí navíc:
- Sloučení struktury převezme model aplikací z vývojové instance celý, takže změnu aplikace provedenou přímo v provozu přepíše. Každou takovou změnu je proto potřeba hned zopakovat i ve vývojové instanci – nebo vývojovou instanci obnovit z aktuální zálohy provozu, pokud v ní nic rozpracovaného není.
- Porovnání instancí před releasem (kapitola Release do provozní instance) ukáže i změny provedené přímo v provozu, které ve vývojové instanci chybí.
- Data zapsaná přímo v provozu release nepřepíše – sloučení data provozní instance zachovává.
6. Když agent chybuje
- Co agent v instanci změnil, ukazuje historie změn záznamů a u skriptů, databázových dotazů a kódu prvků HTML a JavaScript také historie jejich verzí, kterou agent přečte nástrojem „get_model_history“.
- Chybu agenta, dotaz nebo zkušenost s agentním vývojem lze nahlásit přes Helpdesk NetGenia. K rozboru chyby se hodí výpis z historie změn, platná pravidla pro agenta a záznam pokynů, které agent dostal – proto je vhodné konverzace s agentem uchovávat. Osobní údaje, které k pochopení chyby nejsou potřeba, se z podkladů před předáním odstraní.
- Vznikla-li chyba při práci přímo v provozní instanci, může NetGenium rozbor podmínit tím, že se chyba nejdřív zopakuje ve vývojové instanci.
- Každá chyba agenta se promítne do pravidel pro agenta (viz Pravidla pro agenta).