[Javalist] Gondolatébresztő Git gondolatok

[István Viczián]

Üdv,

Kérdezhetek? Mindig is érdekeltek ki hogyan valósítja meg ezeket.
- Pontosan mi az a jenkins-es verifier?
- Hogy jön létre a release branch-re jenkins job, ki hozza létre? Ő
futtatja ezen a teszt eseteket? Mennyi ideig tart?

Köszi,

--
Viczián István


Zsombor <gzsombor at gmail.com> írta (2014. február 23. 21:40):
>
>
>
> 2014-02-23 13:12 GMT+01:00 Auth Gábor <auth.gabor at javaforum.hu>:
>
>> Hi,
>>
>>
>>
>> Zsombor a következőt írta ekkor: 2014. február 22. 20:47:47
>>
>> > Döntsd el, hogy a két projekt független egymástól, vagy sem. Ha
>>
>> > függetlenek, akkor annak a kérdésnek nincs semmi értelme, hogy egyik kód
>>
>> > kikerül az egyik projektből, miközben valami ahhoz hasonló egy tőle
>>
>> > független projektbe bekerül.
>>
>>
>>
>> Szerintem leírtam, hogy mennyire és milyen módon függenek egymástól.
>
>
> Igen, és ezért nem értem, hogy hol ezek után mi a kérdés :)
>
>>
>>
>>
>> > Ha meg nem független - s szerintem egy szerver/kliens alkalmazásnál
>>
>> > tipikusan nem az - akkor meg amúgy is elvárás, hogy legyen integrációs
>>
>> > teszt, amivel biztosíthatod, hogy ha modulok között mozgattál kódokat,
>>
>> > akkor azok tényleg jól kommunikálnak még mindig egymással, a
>> > módosításaid
>>
>> > után is.
>>
>>
>>
>> Nagyon nem értek egyet.
>>
>>
>>
>> > Amúgy nem értem a kérdésed, jenkins tud olyat, hogy ne a gyökér
>>
>> > könyvtárban levő pom.xml-t akarja buildelni,
>>
>>
>>
>> Ok, értem. De, példát nem láttam jó megoldásra, hogy egy Git
>> repository-ban hogy tudok két projektet úgy fordítani, hogy két külön master
>> van, vagy ha egy master van, akkor csak arra a módosításra fordítson, ami az
>> adott ágon van. De ez még egyszerű, a release folyamat viszont már nem
>> egyszerű, mert furán fog kinézni többféle tag, illetve a verziózás is
>> problémás.
>>
>>
>>
>> Visszakérdeznék: hogy néz ki Nálad a release folyamat?
>>
>>
>
>
>
> Nagyjából úgy, ahogy a nagy könyvben meg van írva, van egy nagy repó, benne
> cirka 300 modullal, épül belőle 4-5 webapp, több kevesebb átfedéssel, mind
> snapshot dependenciaként hivatkoznak egymással, s vannak külső függőségek,
> cégen belüli és kívüliek, amikre konkrét verzió számmal van hivatkozás. A
> központi repóba gerrit review-al, és jenkins-es verifier-rel lehet beküldeni
> kódot, ami fordít és futtatja a teszteket. Ezen kívül óránként van
> integrációs build, a bemergelt kódokkal. Ezek után a release annyi, hogy a
> masterből csinálnak egy branch-et, a masteren rögtön a következő snapshot
> verzióra ugranak, a branch-en még fixálgatnak egy keveset, majd tag-elnek
> release-t (ha további gyors fixek is kellenek, akkor már csak a release
> branchet módosítják, stb )
>  Kezdetben próbálkoztak olyannal, hogy legyenek külön repók, nagyobb modul
> csoportokra, de nagy szívás volt, sosem lehetett tudni, hogy melyik repót
> mikor szabad frissíteni, mivel kompatibilis éppen. Egy repositoryban -
> CI-vel megtámogatva - ez természetesen adódik.
>
> Üdv
>  Zs
>
> ui. amúgy egymástól teljesen független projektek is lehetnek egyetlen
> repositoryban, mindenféle közös történelem nélkül is, így meg lehet oldani
> azt amit szeretnél is :) De nyilván elég zavaró tud lenni úgy a helyzet
>
>
>>
>> Bye,
>>
>> Auth Gábor
>>
>> http://www.javaforum.hu/web/10/authgabor
>>
>>
>> _______________________________________________
>> Javalist mailing list
>> Javalist at lists.javaforum.hu
>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>