<div dir="ltr"><div><div><div><div>A jenkins-es verifier a gerrit-be bekerült changeset-eket ellenőrzi, még mielőtt eljutnának a master-be, mivel nem bízunk abban, hogy a fejlesztő változtatása után fordulni fog minden, és minden unit teszt valóban zöld :) Ez nálunk, jelenleg 20-25 perc körüli idő. Itt van leírva mit kell nagyjából csinálni : <a href="https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger">https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger</a><br>
</div> Úgy tudom, hogy a release branch-hez a jenkins job szimplán kézzel jön létre, a jenkins "Copy job from ..." funkcionalitásával, kis átnevezésekkel :)<br></div><br></div>Üdv<br></div> Zs<br><div><div><div>
<div><div><br></div></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-02-23 22:18 GMT+01:00 István Viczián <span dir="ltr"><<a href="mailto:viczian.istvan@gmail.com" target="_blank">viczian.istvan@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Üdv,<br>
<br>
Kérdezhetek? Mindig is érdekeltek ki hogyan valósítja meg ezeket.<br>
- Pontosan mi az a jenkins-es verifier?<br>
- Hogy jön létre a release branch-re jenkins job, ki hozza létre? Ő<br>
futtatja ezen a teszt eseteket? Mennyi ideig tart?<br>
<br>
Köszi,<br>
<br>
--<br>
Viczián István<br>
<br>
<br>
Zsombor <<a href="mailto:gzsombor@gmail.com">gzsombor@gmail.com</a>> írta (2014. február 23. 21:40):<br>
<div class="HOEnZb"><div class="h5">><br>
><br>
><br>
> 2014-02-23 13:12 GMT+01:00 Auth Gábor <<a href="mailto:auth.gabor@javaforum.hu">auth.gabor@javaforum.hu</a>>:<br>
><br>
>> Hi,<br>
>><br>
>><br>
>><br>
>> Zsombor a következőt írta ekkor: 2014. február 22. 20:47:47<br>
>><br>
>> > Döntsd el, hogy a két projekt független egymástól, vagy sem. Ha<br>
>><br>
>> > függetlenek, akkor annak a kérdésnek nincs semmi értelme, hogy egyik kód<br>
>><br>
>> > kikerül az egyik projektből, miközben valami ahhoz hasonló egy tőle<br>
>><br>
>> > független projektbe bekerül.<br>
>><br>
>><br>
>><br>
>> Szerintem leírtam, hogy mennyire és milyen módon függenek egymástól.<br>
><br>
><br>
> Igen, és ezért nem értem, hogy hol ezek után mi a kérdés :)<br>
><br>
>><br>
>><br>
>><br>
>> > Ha meg nem független - s szerintem egy szerver/kliens alkalmazásnál<br>
>><br>
>> > tipikusan nem az - akkor meg amúgy is elvárás, hogy legyen integrációs<br>
>><br>
>> > teszt, amivel biztosíthatod, hogy ha modulok között mozgattál kódokat,<br>
>><br>
>> > akkor azok tényleg jól kommunikálnak még mindig egymással, a<br>
>> > módosításaid<br>
>><br>
>> > után is.<br>
>><br>
>><br>
>><br>
>> Nagyon nem értek egyet.<br>
>><br>
>><br>
>><br>
>> > Amúgy nem értem a kérdésed, jenkins tud olyat, hogy ne a gyökér<br>
>><br>
>> > könyvtárban levő pom.xml-t akarja buildelni,<br>
>><br>
>><br>
>><br>
>> Ok, értem. De, példát nem láttam jó megoldásra, hogy egy Git<br>
>> repository-ban hogy tudok két projektet úgy fordítani, hogy két külön master<br>
>> van, vagy ha egy master van, akkor csak arra a módosításra fordítson, ami az<br>
>> adott ágon van. De ez még egyszerű, a release folyamat viszont már nem<br>
>> egyszerű, mert furán fog kinézni többféle tag, illetve a verziózás is<br>
>> problémás.<br>
>><br>
>><br>
>><br>
>> Visszakérdeznék: hogy néz ki Nálad a release folyamat?<br>
>><br>
>><br>
><br>
><br>
><br>
> Nagyjából úgy, ahogy a nagy könyvben meg van írva, van egy nagy repó, benne<br>
> cirka 300 modullal, épül belőle 4-5 webapp, több kevesebb átfedéssel, mind<br>
> snapshot dependenciaként hivatkoznak egymással, s vannak külső függőségek,<br>
> cégen belüli és kívüliek, amikre konkrét verzió számmal van hivatkozás. A<br>
> központi repóba gerrit review-al, és jenkins-es verifier-rel lehet beküldeni<br>
> kódot, ami fordít és futtatja a teszteket. Ezen kívül óránként van<br>
> integrációs build, a bemergelt kódokkal. Ezek után a release annyi, hogy a<br>
> masterből csinálnak egy branch-et, a masteren rögtön a következő snapshot<br>
> verzióra ugranak, a branch-en még fixálgatnak egy keveset, majd tag-elnek<br>
> release-t (ha további gyors fixek is kellenek, akkor már csak a release<br>
> branchet módosítják, stb )<br>
> Kezdetben próbálkoztak olyannal, hogy legyenek külön repók, nagyobb modul<br>
> csoportokra, de nagy szívás volt, sosem lehetett tudni, hogy melyik repót<br>
> mikor szabad frissíteni, mivel kompatibilis éppen. Egy repositoryban -<br>
> CI-vel megtámogatva - ez természetesen adódik.<br>
><br>
> Üdv<br>
> Zs<br>
><br>
> ui. amúgy egymástól teljesen független projektek is lehetnek egyetlen<br>
> repositoryban, mindenféle közös történelem nélkül is, így meg lehet oldani<br>
> azt amit szeretnél is :) De nyilván elég zavaró tud lenni úgy a helyzet<br>
><br>
><br>
>><br>
>> Bye,<br>
>><br>
>> Auth Gábor<br>
>><br>
>> <a href="http://www.javaforum.hu/web/10/authgabor" target="_blank">http://www.javaforum.hu/web/10/authgabor</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Javalist mailing list<br>
>> <a href="mailto:Javalist@lists.javaforum.hu">Javalist@lists.javaforum.hu</a><br>
>> <a href="http://lists.javaforum.hu/mailman/listinfo/javalist" target="_blank">http://lists.javaforum.hu/mailman/listinfo/javalist</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> Javalist mailing list<br>
> <a href="mailto:Javalist@lists.javaforum.hu">Javalist@lists.javaforum.hu</a><br>
> <a href="http://lists.javaforum.hu/mailman/listinfo/javalist" target="_blank">http://lists.javaforum.hu/mailman/listinfo/javalist</a><br>
><br>
_______________________________________________<br>
Javalist mailing list<br>
<a href="mailto:Javalist@lists.javaforum.hu">Javalist@lists.javaforum.hu</a><br>
<a href="http://lists.javaforum.hu/mailman/listinfo/javalist" target="_blank">http://lists.javaforum.hu/mailman/listinfo/javalist</a><br>
</div></div></blockquote></div><br></div>