Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: vesterna12 01. 03. 2021, 14:29:36
-
Davate prednost psani J. Pipelines v Groovy nebo radeji pouzijete "Bash" scripty?
Jake je vyhoda Groovy v tomto kontextu?
-
dávám přednost bash, ale blbě se automaticky analyzuje, na to je groovy lepší. Největší úlet je ale Jenkins se scripty v bash.
Každopádně, když si ten bash dobře strukturuješ, můžeš tam ledacos dobře implementovat a mít tam určitou možnost automatické kontroly.
-
90% kazdej pipeliny v groovy. Jednak podpora IDE (InteliJ Idea a importnuty konfig z jenkinsu), jednak moznost testovat pipelinu za pomoci nejakeho frameworku (obcas sa zide) a jednak dostupnost informacii o builde (moznost lahko dat daco do description, vyuzit nejaky plugin na ohviezdickovanie buildov / badge, ci moznost jednoducheho paralelizmu, kedy build dokumentacie a vykonavanie testov moze bezat paralelne a je to (subjektivne) strukturovanejsie zapisane ako v bashi). V neposlednom rade juniori maju skor skusenost s groovy, ako s bashom a naucit dakoho ako escapovat v sheli nie je celkom jednoduche :)
PS: Na druhej strane, ked je to v bashi (idealne kompatibilne s /bin/sh vseobecne), tak si clovek spusti "pipeline" aj u seba a vie to lokalne debugovat, bez nutnosti mat pristup na jenkins stroj.
-
to je také důležitý argument, groovy je dobře přenosné v týmu, má ucelenou dokumentaci a je to robustnější nástroj. Psát správně bash je strašně těžké, je potřeba opravdu dobrá zkušenost a jeho znalost, jinak hrozí chyby, problémy. To řikám jako někdo, kdo v bash píše denně.
-
90% kazdej pipeliny v groovy. Jednak podpora IDE (InteliJ Idea a importnuty konfig z jenkinsu), jednak moznost testovat pipelinu za pomoci nejakeho frameworku (obcas sa zide) a jednak dostupnost informacii o builde (moznost lahko dat daco do description, vyuzit nejaky plugin na ohviezdickovanie buildov / badge, ci moznost jednoducheho paralelizmu, kedy build dokumentacie a vykonavanie testov moze bezat paralelne a je to (subjektivne) strukturovanejsie zapisane ako v bashi). V neposlednom rade juniori maju skor skusenost s groovy, ako s bashom a naucit dakoho ako escapovat v sheli nie je celkom jednoduche :)
PS: Na druhej strane, ked je to v bashi (idealne kompatibilne s /bin/sh vseobecne), tak si clovek spusti "pipeline" aj u seba a vie to lokalne debugovat, bez nutnosti mat pristup na jenkins stroj.
To je přesně ta hranice, kterou mám pro sebe.
Groovy používám v Jenkins, pokud to bude jen v Jenkins. Například zobrazit seznam větví z git repo a dát uživateli vybrat, která se má buildit.
Bash - provádění tasku. Instalace aplikace etc. Důvod použití Bash je, že si nastavím env na dev stroji tak, abych to mohl spustit ručně a mám vše v gitu s projektem, takže každá větev může mít trochu jiný build. To se taky někdy hodí.
-
Ideálně to mít poskládané tak, aby se případně dalo lehce změnit build server. To jest groovy jen pro jenkins specifické věci a jinak pouštět skripty v gitu. Např. javě se snažím aby všechny ty skripty začínaly "mvnw..." nebo "gradlew..." protože většina vývojařů v čr používá windows