Názory k článku Aktualizace webových aplikací složených z mnoha různých modulů

Já už nějakou dobu aplikuji aktualizovat verze často a snažit se co nejdříve používat nejnovější verze. Ono to může být pro někoho možná otravné to dělat každý měsíc, ale uspoří to hromadu času a hromadu problémů, než když se to dělá jednou za x let. Navíc pokud je nějaký problém v nejnovější verzi, tak se často velmi rychle odhalí a opraví. O tom, že ty časté aktualizace jsou mnohem snazší než když se dělá jeden big bang upgrade není třeba ani mluvit.
Předpokladem tohohle řešení je mít většinu pokrytou testy a sledovat co se děje ve frameworku, knihovnách nového.

Což se dá, pokud těch projektů máte málo nebo ne příliš komplexních.
Ale pokud používáte více složitých aplikací a stojí na tom provoz firmy, často nezbývá, než si na analýzu nechat čas a postupně procházet jednu apku po druhé v několikaměsíčním cyklu - a ještě hlídat updaty systému a prerekvizit.

Tak teď je to přes 30 microservice. Některé jsou jednoduché některé složité. Rozhodně bych neřekl, že nejsou komplexní. Používá se tam tak 5 různých data sources od PostgreSQL, MongoDB přes elasticsearch až po Azure ( což je vždy ten největší pain). Update neznamená okamžité nasazení na produkční prostředí. Musí to projít přes dev a staging. Vždy to dělám tak že výběru jednu komplexní a tu updatuji a nechám týden na dev. Pokud vše funguje updatuji zbytek. Pak posunu jednu microservice dále až na prod a opět nechám chvíli běžet. Pokud je vše ok, tak zbytek nasazují na prod až s jinými změnami.
Takže mám vlastně 4 záchytné body, testy v aplikaci, integrační testy, dev a staging a teprve pak to jde do produkce. Pokud to někdo dělá rovnou na produkci a nebo bez dostatečných testů, tak se pak není čemu divit, že to trvá dlouho. Ono se spíš ukáže, že to je vždy lenost resp. ochota někoho kdo tohle bude dělat, protože výsledek není úplně vidět. Odměnou je spokojený vývojářský tým, security, lepší domluva s vývojáři knihoven/frame­worků. A nemusíte řešit pak velké updaty, kde se pak každý boji to udělat, protože neví co se za těch x verzi kde změnilo.

Coz indikuje, ze to delas pro sebe na nejakym pidiwebu, ktery neni navazan nikam dal. Pokud nekdo provozuje neco komercne, tak tohle delat nebude, pokud neni blazen, protoze to typicky znamena neustale predelavat vse, co je na web navazano.

Mna skor stve, ze dnes sa uz uplne kasle na semanticke verzovanie. napriklad v JS tak to verzuju ako chcu a potom mame pripady softveru, ktory to verzuje cislom roku v ktorom vznikol.

to verzování je jen důsledek, spousty SW vývojářů si osvojili neudržovat staré verze a nedělat backporty oprav, inkrementální verzování je pak jen důsledek a nic se nezmění, kdyby semanticky verzovali a staré verze neudržovali.

Je to na rozhodnutí vývojářů jak budou svůj SW dělat a jsem rád, když to řeknou veřejně třeba formou verzování, pak aspoň vím, co čekat.

Díky Zdeňku za článek.

Když jsem v začátcích mapoval terén pro "Rychlé weby", bylo vidět, že to co si v NICu pod tím představují nepůjde dělat jen staticky přes Pelican, tak z toho Django CMS vypadlo jako schůdná volba.

Ale vybalancovat mezi pluginy, kde spousta končila ještě u Pythonu 2.x a jiné vyžadovaly 3.x, fungující v různých verzích Djanga, ..., to bylo pěkné dependency peklíčko.

Varianta převzít plugin/y pod svá křídla, to vyžaduje odvahu a zázemí.
Ať se vám daří tu "káru" tlačit dál.

PS: V textu odkazu, ve větě: "K tomu jsme použili nástroj pyugrade," ukousl šotek písmeno "p".

6. 12. 2023, 13:41 editováno autorem komentáře