Új hozzászólás Aktív témák

• wis tag

  #10237

  #10236 MrSealRD

  2019-01-15 16:39:53

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  wis

  tag

  #10236 MrSealRD

  #10236 MrSealRD

  Helló!
  Nem teljesen Java téma, de mivel Java-s projekt így gondoltam elférhet ide, de ha van jobb helye akkor átmegyek...

  Szóval adott egy projekt aminek a forrása Git verziókezelőben van tárolva. A buildre Jenkins haszálunk. Az elkészült build/release pedig nexusban tároljuk...
  Az eredeti elképzelés szerint van a M(master) branch amit tisztán akarunk tartani. Ezért amikor van egy-egy nagyobb projekt ami több feladatot fog össze, arra a célra létrejön mindig egy xxxPM nevű branch. Ebből nyit a továbbiakban mindenki új branchet a saját feladatára. Amikor kész akkor szintén az xxxPM-be megy vissza a merge.
  Van még egy U és egy UAT környezet tesztelésre. Alapvetően az az irány, hogy U-ra snapshot míg UAT-ra release verzió kerül ki.

  Több probléma is kialakult.

  1. Jenkinsben 1 job egy adott branchre buildel. Alapból ez a master. De valamiért kitalálták, hogy az xxxPM branchből készülő buildeket ezentúl ne lokálisan készítsük, hanem Jenkinsben... Ezért létrehoztak neki egy külön jobot. Ilyen projektekből több is van, időnként párhuzamosan is, ezért a dedikált jenkins job szerintem nem jó ötlet. A gányolás melegágya az én meglátásom szerint. Nem lehet dinamikusan kezelni. Újabb projektél újabb job?! De meddig?! Ha vége akkor meg átállítjuk egy újra?!

  2. Az előbbi problémából következett egy másik. Az M branch közben haladt előre, de az xxxPM nem lett frissítve a változásokkal... Ez már egy nagy hiba volt, tudom. De ettől függetlenül, most megjelent az igény, hogy az xxxPM-ből is legyen release. Nem azért mert ez valaha is élesedhet, hanem azért, hogy UAT-ra tudjanak tenni verziót a laikusoknak, hogy teszteljenek... Tudják, hogy ez nem fog élesedni mert még nincs kész, nincs olyan állapotban. Csak kizárólag a teszt miatt. Ráadásul még két tagot hozzá kell csapni a verziószámhoz, hogy az állapotot jelöljük, így létrejön egy kvázi párhuzamos valóság... Valahogy ezt sem érzem egy kifinomult megoldásnak.

  Érdekelne, hogy mi a meglátásotok, illetve, hogyan történnek az ilyen folyamatok nálatok?

  1. A buildelendő branch (vagy tag vagy SHA) jöjjön Jenkins paraméterből, így nem kell mindhez új job.
  2. A verziószám is jöhet paraméterből, vagy használhatod a build numbert az egyediséghez.

Új hozzászólás Aktív témák