Update z Java 8 na Java 11. Je to bezproblémová rychlovka nebo proces, který vám připraví nejednu překážku? Náš kolega Standa Keppert měl možnost se do tohoto přechodu zapojit a již v minulém článku s námi sdílel několik zajímavých zkušeností, které na projektu vypozoroval.
Co ze zákulisí nám ještě může prozradit a jak by celý přechod shrnul?
V minulé části se můžete dočíst, co konkrétně se upgradovalo a jak. Nyní se mrkneme, jak byl celý přechod zorganizovaný, kolik času zabral a jak bychom ho celkově zhodnotili.
Upgrade byl rozdělen v rámci dvou sprintů do několika fází. V první fázi se přepisoval kód a připravovaly se kontejnery v Dockeru, časový odhad byl 7 MD, nakonec fáze zabrala 11 MD a pracovali na ní dva vývojáři. Hlavní důvod jejího prodloužení byl problém se stabilitou vytvořených Docker kontejnerů. Použitá starší verze Dockeru byla dostačující pro JAVA 8 avšak s přechodem na JAVA 11 už nestačila a způsobovala zmíněnou nestabilitu. Přešli jsme tedy na novější verzi a pak vše již šlapalo jako švýcarské hodinky.
Když vývojáři dokončili úpravy kódu na všech modulech, začalo se postupně nasazovat. Jak jsem ale psal již v první části, tyto updaty nebyly ze začátku úplně v pořádku.
(pozn. redakce: Upravili jsme jednu část kódu (jeden modul) a předpokládali, že jeho druhá část (druhý modul) nebude mít problémy se zpracováním dat. Bohužel spolu obě části kódu přestaly dobře komunikovat. Z toho důvodu se prováděl následný downgrade aby vše začalo zase pracovat. Úplně se oddělila nová Branch a celý kód jsme přepsali a upravili na jiném serveru, kde se zároveň i vše testovalo pomoci automatického testovacího frameworku.)
Do úprav, které vývojář ladil, bylo začleněno i testování pomocí automatického testovacího frameworku. Měli jsme upravený automatický testovací nástroj pro BE volání. Vytvořil jsem i konfigurovatelný Jenkins job, díky kterému si mohl vývojář testovat konkrétní modul.
Tato akce se nestihla v plánovaném časovém úseku, bylo tedy potřeba ji přesunout na nové speciálně vytvořené vývojové prostředí, kam se všechny moduly přesunuly a upravovaly se. Jakmile se každý z modulů upravil, byl nasazen a nahradil předchozí verzi, která běžela v Java 8. Vše zabralo dalších 5 MD, a tak celý přechod trval dva sprinty.
Není přechod jako přechod
V našem případě jsme se při přechodu potýkali hned s několika problémy, to ale neznamená, že se musí objevit vždy. Četl jsem o případech, kdy byl přechod rychlý bez větších komplikací i naopak o takových, kdy se problémy nakupily a přechod zabral ještě více času než nám.
Na našem projektu byl přechod o něco složitější i díky tomu, že se na kódu pracovalo hodně dlouho a střídali se různé týmy. Nakonec jsme se ale dobrali zdárnému konci a vše, včetně automatizovaného testovacího frameworku (zatím ale pouze backend testy, frontend jsou zatím odložené na neurčito) již plně funguje na Java 11. Ještě bude potřeba udělat pár úprav v rámci Selenium webdriver, ale to už nebude tak náročné, jako to měli například vývojáři, když museli předělávat celou rozsáhlou aplikaci.
Celý přechod byl v našem případě zakončen na Sprint Review, kde jsme sdíleli problémy, se kterými jsme se potýkali a obecně lessons learned v celém týmu. Nakonec se informoval business, že vše již běží na Java 11 a mohli jsme se pustit zase do další práce ?.
Máte i vy konkrétní zkušenosti s přechodem na nové verze Java? Podělte se s námi, budeme rádi.
🟡 Hledáte zajímavý projekt? Mrkněte, jak to u nás chodí a jaké kolegy aktuálně hledáme.
🟡 Máte kolegu nebo kamaráda, který se poohlíží po novém projektu? Zapojte se do našeho referral programu Doporuč a získejte finanční odměnu za doporučení.
🟡 Chtěli byste začít pracovat v IT? Stáhněte si náš ebook ZAČNĚTE PRACOVAT V IT: aneb od prvních krůčků po vysněnou práci, ve kterém vás provedeme krůček po krůčku informacemi, kurzy i praxí, které jsou tolik potřebné nejen pro ty, kteří chtějí změnit obor, ale i pro ty, kteří se chtějí pracovně posunout a dále se vzdělávat.
Nebo sdílejte tento článek, který třeba poslouží i vašim známým.
