Základem tohoto seznamu jsou mnohaleté zkušenosti s podporou automatizace pro tým upstream kontejnerů (podman, buildah, skopeo atd.). Nebudu brát plné uznání, protože mnoho z těchto tipů je založeno na amalgámu vyvinutých zkušeností a individuálních příspěvků od velké komunity uživatelů a vývojářů.
Většinu položek níže lze zredukovat na jeden princip:Odstranění nebo snížení složitosti . Tento koncept je založen na složené aplikaci Murphyho zákona :Čím více „rozbitných věcí“ máte, tím je pravděpodobnější, že se objeví Murphy. Zde je osm způsobů, jak se těmto náhodným setkáním vyhnout.
[ Čtenářům se také líbilo: Představujeme nový Ansible Automation Hub ]
1. Snižte síťové závislosti
Snižte síťové závislosti, zejména na službách třetích stran, nad kterými nemáte žádnou kontrolu. Síťové služby první a druhé strany by navíc měly být považovány za „vyhněte se, pokud je to možné“. Toto doporučení má ve skutečnosti dva aspekty:
- Ze všech hledisek je vytváření sítí velmi složitý systém souvisejících komponent a vztahů v reálném čase. Obecně řečeno, tyto všechny musí fungovat téměř bezchybně z jednoho konce na druhý, jinak byste mohli mít špatný den.
- Opět, obecně řečeno, selhání sítě jsou často přechodná a závislá na čase (každý je chce rychle opravit). To může neuvěřitelně ztížit následné ladění. I při rozsáhlém protokolování mohou nepozorované účinky začít váš špatný den.
2. Snižte softwarové závislosti
Kde je to možné, omezte softwarové závislosti, zejména na knihovnách třetích stran. To zahrnuje jak váš hlavní předmět automatizace, tak jakýkoli sdílený automatizační kód. Pokud nezamknete verzi každou jednotlivou komponentu nahoru a dolů, riskujete poškození kvůli neočekávanému chování nebo změnám API někde. Situace je o něco lepší, když kontrolujete zahrnutý kód, ale stále představuje riziko.
Poznámka :Uznávám, že tento tip může být poměrně kontroverzní a v mnoha situacích rozhodně nedává smysl. Považujte to za připomenutí „zamyslete se dvakrát“, zvláště když zjistíte, že chcete, aby knihovna přinesla jednu jednoduchou funkci.
3. Uspořádejte automatizační úlohy
Uspořádejte automatizační úlohy v pořadí sestupně podle následků selhání. Jinými slovy, pokuste se co nejdříve zachytit položky s největším negativním dopadem. Myšlenkou je ušetřit zdroje (včetně času) pro vysoce účinné a levné "Whoopsies" s nízkými náklady na detekci. Některé příklady testování průběžné integrace VCS (CI):
- Jsou vaše síťové služby třetích stran dostupné? Lze na ně například pingnout a ověřit jejich certifikáty SSL?
- Odpovídá váš kód dodavatele nebo zahrnutý kód skutečně zdokumentovanému a nakonfigurovanému seznamu požadavků?
- Nezanechal někdo náhodou komentář „FIXME“ v nově zadaném kódu?
- Jsou podepsány všechny nové potvrzení?
- Odpovídají změny kontextu provádění, např. nezdokumentované změny během testování vydání nebo chybějící aktualizace dokumentace/testu se změnou kódu?
V průběhu času je výsledkem tohoto pracovního postupu to, že důležitým kontrolám bude věnována největší pozornost a nejspolehlivější údržba (protože poruchy mají tendenci zdržet celý vlak). Vývojáři zase budou moci jezdit rychleji. Například nebudou dlouho čekat, aby zjistili, že špatně napsali své vlastní jméno.
4. Udržujte úlohy krátké
Udržujte úlohy co nejkratší a ve snadno opakovatelných „kusech“. To bude do značné míry záviset na softwaru pro orchestraci, ale většina aplikací umožňuje několik fází provádění. Pokud použijete jiný příklad testování CI, pokud máte spustit testy jednotky, integrace a systému (v tomto pořadí), vyhněte se jejich spouštění dohromady, jeden po druhém, v jediném skriptu. Tímto způsobem, pokud integrační krok selže, uživatelé nejsou nuceni znovu spouštět testy jednotek. Tím se zvyšuje spolehlivost tím, že se neprovádějí nadbytečné operace, což zbytečně zve Murphyho zpět do automatizačního soukolí.
5. Vyhněte se nepodstatným operacím za běhu
Vyhněte se nepodstatným operacím (jako je instalace nebo konfigurace) za běhu. Místo toho si předem připravte prováděcí prostředí se všemi nezbytnými bity. Nejen, že věci běží efektivněji, ale také pomáhá dodržovat další tipy v tomto článku. Umožňuje také pozorování a testování předem sestaveného prostředí v době sestavení. Pokud jsou vaše prostředí sdílena mezi úlohami s některými odlišnými požadavky, zvažte uložení těchto součástí/balíčků do mezipaměti v rámci obrazu. Instalace za běhu z místní mezipaměti je mnohem bezpečnější a spolehlivější než zásah do vzdáleného úložiště přes síť.
6. Používejte správné nástroje
Používejte nejzákladnější dostupné nástroje pro daný úkol. Pokud například potřebujete ověřit binární příznaky po použití bitové masky, nepokoušejte se o to ve skriptu bash. Podobně, pokud váš program v C++ jednoduše provádí řadu příkazů, použijte místo toho bash. To zvyšuje spolehlivost tím, že operace nejsou vystaveny vedlejším účinkům, které nesouvisejí s hlavním účelem úlohy.
7. Sledování selhání
Sledujte selhání na základě četnosti jejich podpisu. Většinu času (ale ne všechny) povedou selhání automatizace k tomu, že se někde zaznamená nějaká indikace. Identifikujte je a klasifikujte (např. podle názvu požadavku), abyste mohli vést centralizovaný záznam výskytu. Pravděpodobně to vyžaduje docela dost práce, než se to podaří, možná to bude vyžadovat, abyste se naučili a propojili se s více službami a rozhraními API. S výsledky seřazenými podle frekvence podpisů však rychle zjistíte, které problémy se týkají největšího počtu lidí. Těmto položkám by měla být věnována největší pozornost a budou mít největší dopad na spolehlivost automatizace.
8. Používejte komentáře efektivně
Komentář proč nikoli jak . Předpokládejme, že každý čtenář vašeho kódu může určit způsob jeho fungování. Nemohou určit, co jste si (autor) mysleli, když jste psal kód. Automatizace zahrnuje mnoho pohyblivých částí. Některé vztahy nemusí být nezasvěcenému čtenáři zřejmé. Komentáře jsou zvláště užitečné, když informují o vztazích mezi komponentami.
Zvažte například následující komentář:
# Default variable value comes from CI unless executed manually.
# Detect this (`$CI == false`) to ensure the user did not leave
# the value blank. Měli byste si snadno představit kód, který to zdobí – nějakou formu definice nebo ověření proměnné. Dále to naznačovalo další zdroj informací, "CI" (ať už to v kontextu skriptu znamená cokoli).
Užitečné komentáře, jako je tento, nemusí zdobit každý řádek vašeho skriptu; zaměřit se na ně. Zaměřte se na předměty ovlivněné externími soubory nebo silami (včetně slunečních erupcí). Tyto detaily zvyšují spolehlivost automatizace tím, že zajišťují, že „tajná omáčka“ je neustále předávána každému, kdo bude pověřen budoucími vylepšeními nebo údržbou.
[ Bezplatný průvodce od společnosti Red Hat:5 kroků k automatizaci vašeho podnikání. ]
Sbalit
Ve většině situací nebude možné dodržet všechny tyto rady. Mají sloužit jako vodítko pro kompromis, když jsou rozumné alternativní implementace. V opačném případě bude někdy nutné porušit některé z těchto zásad, aby co nejlépe sloužilo svým zainteresovaným stranám. Přesto ostatní (jako psaní dobrých komentářů) budou mít v průběhu času tendenci mít jemný, ale stabilní účinek. Budu první, kdo připustí, že dělat věci jednoduše je často mnohem obtížnější než plácat do lepicí pásky. Po určité době však většina lepicí pásky vyschne a zkoroduje, což vyžaduje, abyste problém znovu opravili. Udělejte laskavost svému budoucímu já, věnujte čas refaktorizaci směrem k jednoduchosti od začátku.