https://wiki.rettungsdienstblog.eu/api.php?action=feedcontributions&feedformat=atom&user=Lachlan82L 2026-09-23T13:37:11Z Benutzerbeiträge MediaWiki 1.37.1 https://wiki.rettungsdienstblog.eu/index.php?title=DevOps,_o_kter%C3%A9m_v%C4%9Bt%C5%A1ina_za%C4%8D%C3%A1te%C4%8Dn%C3%ADk%C5%AF_zakopne&diff=205262 2026-08-29T05:21:43Z

<p>Lachlan82L: </p> <hr /> <div>Další pastí je nesprávné nastavení oprávnění pro token. Pokud potřebujete nasadit na vzdálený server, použijte buď osobní přístupový token, nebo nasadzovací klíč. Nejbezpečnější je vytvořit samostatný deploy token s minimálními právy, který uložíte do Secrets v nastavení repozitáře. Nikdy nedávejte token přímo do YAML souboru, protože by se mohl dostat do historie commitů. Vždy odkazujte na proměnnou, třeba $ secrets.DEPLOY_TOKEN , a v nastavení repozitáře ji definujte.&lt;br&gt;&lt;br&gt;Posledním doporučením je testovat pipeline na menší větvi, ne rovnou na main. Vytvořte si větvičku s názvem test-actions, kde si ověříte, že všechny kroky fungují, a teprve poté změnu sloučíte. Tím se vyhnete situaci, kdy rozbijete produkční nasazení kvůli překlepu v YAML. Až budete mít pipeline stabilní, můžete přidat i nasazení do stagingu před produkci, aby se chyby odhalily dřív.&lt;br&gt;&lt;br&gt;Stabilita databáze také závisí na správě připojení. Sdílená připojení jsou sice úsporná, ale pokud je aplikace používá nesprávně, může dojít k vyčerpání dostupných připojení a k pádu celého systému. Nastavte si maximální počet připojení, časové limity a nezapomeňte na ověření, že se připojení po dokončení transakce správně uvolňuje. Častou chybou je držet připojení otevřené při dlouhých operacích nebo při čekání na uživatelský vstup – to zbytečně blokuje zdroje a zhoršuje odezvu pro ostatní uživatele.&lt;br&gt;&lt;br&gt;Při psaní testů se také vyplatí myslet na to, co přesně testujete. Pokud testujete funkci, která počítá cenu s DPH, netestujte zároveň i databázové spojení. To už je integrační test. Jednotkové testy mají být rychlé, izolované a bez vedlejších efektů. Pokud potřebujete testovat závislost na vnějším systému, použijte mock. Ale mockování má také své úskalí – pokud zamockujete příliš mnoho, test přestane testovat skutečnou logiku a začne testovat jen to, jak jste mock nastavili. Zamockujte jen to, co je nezbytně nutné, a zbytek nechte běžet reálně.&lt;br&gt;&lt;br&gt;Nakonec se zamyslete nad tím, co se stane, když databáze přestane být dostupná. Aplikace by měla umět elegantně zpracovat výpadek – zobrazit uživateli srozumitelnou hlášku, uložit rozpracovaná data do dočasného úložiště a po obnovení spojení se synchronizovat. Mít záložní server je sice užitečné, ale pokud aplikace neumí přepnout na něj automaticky, je to jen další komplikace. Naplánujte si scénáře selhání a otestujte je dříve, než k nim dojde v produkčním prostředí.&lt;br&gt;&lt;br&gt;Když zákazník požádá o odhad času, většina z nás automaticky vsadí na optimismus. V duchu si řekneme, že to stihneme dřív, a sdělíme termín, který nás pak dostane pod tlak. Výsledek? Zpoždění, omluvy a zákazník, který vám přestane věřit. Přitom stačí změnit způsob, jakým o čase mluvíte, a komunikace se stane nástrojem důvěry místo zdrojem stresu.&lt;br&gt;&lt;br&gt;Častou chybou je také snažit se odhadnout čas bez dostatečných informací. Než cokoli slíbíte, zeptejte se na detaily zadání. Čím víc toho víte o rozsahu práce, tím přesnější odhad můžete dát. Pokud informace chybí, řekněte to na rovinu: „Teprve po analýze zadání vám dám konkrétnější termín.&quot; Zákazník ocení, že nejednáte naslepo. Když se ale zadání během práce změní, nebojte se odhad aktualizovat. Mlčet až do termínu a pak omlouvat zpoždění je to nejhorší, co můžete udělat. Včasná komunikace o novém odhadu je známkou profesionality.&lt;br&gt;&lt;br&gt;Když už máte první službu v CI, zaměřte se na měření. Klíčové metriky nejsou počet nasazení za den, ale doba od nápadu po produkci a frekvence selhání. Zapisujte si čísla do tabulky, ale neanalyzujte je každý den — stačí týdenní revize. Pokud vidíte, že jsou nasazení častější, ale výpadky se nemění, děláte to dobře. Když se ale výpadky začnou množit, přibrzděte a přidejte víc testů, ne další automatizace.&lt;br&gt;&lt;br&gt;Jak sestavit efektivní kroky a vyhnout se častým chybám Pište kroky tak, aby byly co nejkratší a nejpřehlednější. Jeden krok by měl dělat jednu věc – checkout, instalace závislostí, testy, build, nasazení. Typickou chybou je kombinovat více příkazů do jednoho kroku, což ztěžuje ladění a případné opakování. Místo toho použijte samostatné kroky s jasným názvem, třeba „npm install&quot; a „npm test&quot;. Pokud některý krok selže, GitHub Actions vám ukáže přesně, který to byl, a vy nemusíte procházet celý log.&lt;br&gt;&lt;br&gt;Typické chyby, které kazí dojem z aplikace Mezi nejčastější prohřešky patří ignorování stavu načítání. Když uživatel klikne na tlačítko a nic se neděje, má pocit, že se aplikace zasekla. Vždy poskytněte zpětnou vazbu – ať už jde o spinner, změnu barvy tlačítka nebo text „Ukládám…&quot;. Stejně důležité je ošetřit chybové stavy: místo obecného „Došlo k chybě&quot; napište konkrétně, co se nepovedlo a jak to uživatel může opravit. Například „Zkontrolujte připojení k internetu&quot; nebo „Zadané heslo je příliš krátké&quot;. Uživatel pak nemusí hádat a může problém rychle vyřešit.</div>

Lachlan82L https://wiki.rettungsdienstblog.eu/index.php?title=Benutzer:Lachlan82L&diff=205259 2026-08-29T05:21:40Z

<p>Lachlan82L: Die Seite wurde neu angelegt: „Váš průvodce dílnou i obývákem sází na osvědčené tipy. Píšu o tom, jak skloubit funkčnost s teplem domova. Nejraději hledat cesty, jak si usnadnit život.“</p> <hr /> <div>Váš průvodce dílnou i obývákem sází na osvědčené tipy. Píšu o tom, jak skloubit funkčnost s teplem domova. Nejraději hledat cesty, jak si usnadnit život.</div>

Lachlan82L