Síla kontejnerizace. Bezpečně na vlastním písku
Pátý díl seriálu o agilním řízení, který se zaměřuje na techniky, jež dokážou proměnit velké týmy a složité projekty v efektivní a spolupracující systémy. Jako další přichází na řadu metoda zvaná kontejnerizace vývojového prostředí.
Větší firmy, které ještě používají legacy architektury, se potýkají s jedním problémem: jejich systémy jsou všechny navzájem propojené, a pokud je potřeba je testovat end-to-end, musí jich najednou běžet velký počet, všechny musí být naplněné daty a všechny musí běžet v určitém stavu. Tomu se říká prostředí.
Každý takový systém má své produkční prostředí – to, co běží v reálu pro skutečné zákazníky – a potom určitý počet testovacích, integračních a vývojových prostředí. Na těch běží kopie daného softwaru a pro různé účely existují v různých nastaveních.
Rozbitost jako setrvalý stav
Pokud se tohle všechno má blížit produkčnímu prostředí, a tedy, jak jsme řekli, toho musí běžet spousta, prostředí trpí. Jeho provoz je drahý a firmy většinou také postrádají dostatečnou kapacitu. Je běžné, že prostředí se neustále nachází v určitém stupni rozbitosti a nespolehlivosti. Pohybuje se v něm totiž velké množství různých týmů, které v různých časech na různá místa vkládají rozmanité a navzájem nekompatibilní požadavky a změny.
Nezmeškejte žádné novinky ITT
Výsledek? Prodražuje se integrace, testování a vlastně i pouhé uvědomění si toho, zda daná věc funguje tak, jak má. Ruku v ruce s tím jde i druhá záležitost: vývojová prostředí, v nichž nejde pouze o běh samotné aplikace nebo systému, ale i o vývojové nástroje, všemožné měřiče či kompilátory. Ty vyžadují spoustu různých nastavení, což většinou vývojáři udržují na svých vlastních počítačích – na každém operačním systému trochu jinak, v různých verzích a podobně. Zmatek.
Jak z něj ven?
Jednou cestou je kontejnerizace vývojového prostředí.
Takový kontejner je virtuální prostředí, které může běžet buď na lokálním počítači, nebo v cloudu. Obsahuje buď konkrétní přesné nastavení běhové aplikace, kterou vyvíjíme, nebo jde o takzvaný vývojový kontejner, v němž máme celé své vývojové prostředí.
Velkou výhodou takového kontejneru je, že jej lze velice snadno replikovat, lze ho držet v libovolném počtu instancí – každý vývojář nebo tým tak mohou mít svou vlastní instanci kontejneru, která základní nastavení naprosto přesně replikuje.
V případě vyvíjených aplikací jsme tímto způsobem schopni vytvořit celé velké vývojové prostředí levněji, než jak na to jde ona výše popsaná tradiční metoda, a snáz jej naplnit protokolovatelnými daty (která pochopitelně i tady musí někdo udržovat).
Cílem je pomoci týmům, které testují aplikaci end-to-end v nějakém větším prostředí, aby měly svou vlastní kopii a nemusely se bát, že jim jejich práci kdosi v nepředvídatelné chvíli rozbije.
Málo prostoru pro spory
Zároveň vývojáři mohou mít své vlastní vývojové kontejnery, ve kterých mají i nastavení veškerých vývojových nástrojů – všichni stejné. To eliminuje neustálé spory o to, proč někomu něco nefunguje nebo funguje jinak, protože má něco nastavené odlišně, klidně i jen maličko odlišně než ostatní.
V kontejneru to je všechno stejné. Jak už zaznělo, kontejner běží buď na lokálním počítači v nějakém virtuálním stroji, nebo v cloudu.
Ke kontejneru se pak připojím z jakéhokoliv počítače odkudkoliv, a jakmile mám hotovo, zastavím ho a výpočetní výkon může využívat zase někdo jiný.
Tohle je cesta, jak usnadnit přípravu vývojového prostředí, jak usnadnit jeho správu a eliminovat zbytečné problémy plynoucí z toho, že někdo má něco nastavené trochu jinak. A co se aplikačních prostředí týká, mělo by to usnadnit i integraci a testování, a tím pádem zrychlit i smyčku zpětných rozběhů u zákazníků.
Zde se nabízí i propojení s trunk-based developmentem, který jsme probírali dříve. Jedná se pochopitelně o dvě nezávislé techniky, ale pokud máme vysokou míru automatizace, testování, a tudíž onen žádoucí continuous-integration trunk-based development, můžeme udržovat svou aplikaci neustále ve funkčním stavu, můžeme aktualizovat i kontejnery na nejnovější verze a usnadnit tím testování i ostatním týmům, které daný kontejner využívají pro testování svých věcí.