( kroozo | 2024. 07. 26., p – 10:59 )

hogy azon ők is nyerjenek valamit és ne csak erőszakoskodás legyen h. márpedig így kell mert ezt írja a "hogyan kezeljük a kódot normálisan" doksi.

Hát pedig. Szóval én teljesen megértem, hogy próbálsz kooperatív lenni, én se szeretem a márpedig mostantól így lesz... de... szóval itt nem az a baj, hogy lehetne a fejlesztés folyamatain javítani, hanem az, hogy láthatólag egyáltalán nincsenek.  Ez a fejlesztő csapat semmilyen szakmai norma alapján nem végzi el a feladatait, csak gányolják a kódot. Ha te ebbe oldalról jössz, akkor őszintén szólva a saját sírod ásod, ha segítő szándékkal próbálsz alájuk tenni valamit. Úgyse lesz jó (semmi se tud jó lenni ilyen keretek között, mert nem lehet mindent ad-hoc megbaszni, hogy most épp jó legyen, bele fogja verni a fejét a keretbe, meg hülye lesz és nem fogja érteni, mit kell csinálni), és természetesen te leszel a hibás, meg ez az ostoba szarságod, amit ide tettél nekünk, és majd lehet még téged blamelni, hogy miattad nem mennek a dolgok. Ennek a kuplerájnak nem eszközt kell adni a kezébe, hogy hátha így jobb lesz, hanem requirement listát meg felelősséget, hogy az ő dolguk ezt megoldani. Aztán, ha jönnek azzal, hogy a saját dolgukhoz kellene valami, akkor lehet nekik segíteni.

És egyébként ahol ennyire szar sincs, ott teljesen jó stratégia, hogy a "hogyan kezeljük normálisan a kódot" doksiból kiválasztunk valami egyszerűt, és elkezdjük használni, hogy legyen egy bármilyen processz. És ha az már van, akkor lehet majd rájönni, hogy ez hány helyen nem jó, és hogyan kéne jobban csinálni. És amelyik fejlesztő csapat nem tud nagyjából instant elkezdeni használni legalább egy feature branches/mr-es modellt, azt egyben kell kibaszni a picsába, tök őszintén.

---

Hogy azért konkrétumot is írjak :)

Én nem nagyon hiszek abban, hogy vannak itt valódi függőségek, ez a nagyobb kell legyen a verzió ez simán csak egy hiedelem, a gyakorlatban az lesz a valóság, hogy pont azzal, ami pont akkor mellette volt tud fordulni meg működni, a nagyobb verzióval kis szerencsével lefordul (nem változott meg API, amit ugye basznak valójában követni), nagy szerencsével még azt is fogja csinálni, amit az ember gondol (mert nem változott meg a működés sem). Szóval szerintem tagre/gombra nyugodtan előállhat egy olyan verziójú artifact mindenből, azt jóccakát. Ha nagyon kell ez a fantom lófasz, akkor kell csinálni pipeline paramétereket, ahova beleírja azt, amit kb eddig is adhoc csinált: Melyik foldert buildelje le milyen verzióval, aztán azt csinálja meg a pipeline, a végén meg tageljen ő egyet.

Az, hogy egy monorepóból build time egyes részekből nem jó az, ami az aktuális commiton az állapot, azt gitlab ci-val zuzu petals csinálni, valami scripttel alá kell nyúlni, azt össze kell vadászni az apiból, meg másolgatni egy megfelelő állapotú working copyt. Máshol is szar ezt csinálni, de mivel a gitlabban minden a repo köré van szervezve, ezért gyak alágányolni tudsz csak. Máshol (jenkins, tc, akármi) a standard eszközökkel azért könnyebb, hogy van több git forrás, azt pakolod össze a pipelineban.