Code review eszköz kerestetik

Posted by | · · · · | Szoftverfejlesztés | 4 hozzászólás Code review eszköz kerestetik című bejegyzéshez

Mi az a code review eszköz?

A legismertebb a gerrit. Nagy a felhasználótábora, és nagy cég van mögötte. Tehát ideális választás. Gondoltam ez a válasz. Miután elég sokat megtudtam a gerritről, és ki is próbáltam, muszáj volt mégis megválaszolni a kérdést.

Mi az a code review eszköz?

Számomra egy olyan eszköz, ami azt gátolja meg, hogy a forráskódból kimásolt részletek mellé fűzött megjegyzéseim note-okban tároljam, majd címzettenként kötegelve email-en, vagy irc-n küldjem el.
-Nem, nem baseball ütő.

Ennyit szeretnék:

Lehessen megjegyzést fűzni a kommitolt kódsorokhoz, és arról kapjanak az érintettek (én, és aki a kódot elkövette) használható email értesítést. Fontos szempont persze, hogy a felületen normálisan legyen olvasható a kód, és mindenki elérje. Csak nyílt forrású eszköz jöhet szóba, és nem akarok fizetni érte.

Eddig nem tűnik nagy igénynek, még ha az utolsó szempont önző is.

Gerrit

Miközben a gerritet kerülgettem arra kellett rájönnöm, sokkal fontosabb kérdés, hogy mit ne csináljon az eszköz:
Ne akarja meghatározni a csapat munkafolyamatait.
Ne akarjon központi repository lenni, főleg saját pilóta-vizsgás jogosultságkezeléssel.
Ne akarja megmondani, hogy hogyan lehet kommitolni a projektbe, melyik ágra, és milyen paranccsal.

Az se tetszett, ahogy a git-et erőszakolja. Gyakorlatilag zárójelbe teszi a history kezelését.
Az amend parancsot, ami arra lett kitalálva, hogy utólag még nagyon gyorsan ki lehessen javítani egy kommit-ot pusholás előtt -hogy ne kerüljön a történetbe- , a review alapján történő javítás eszközévé teszi. Így minden javításkor újraírjuk a történetet.
Az el nem fogadott kommit pedig blokkolja, és javításkor rebase-re kényszeríti az összes ráépülő többit.
Ez mind nem hiba, hanem feature. Ez a működés a cél.

Pre commit review

Csak a kicsiszolt, elfogadott kommit kerül a történetbe. Egy Android méretű projektnél úgy tűnik ez a járható út.
A reviewboard-ra is rápillantottam, az is ezt a módot támogatja. Ott nem széllel szemben használják a git-et, és több scm-et is tud. Cserébe plusz eszköz van a review request beküldéséhez.

Post-commit review

Vagy másnéven audit. Lassan leesett, hogy igazából ilyet keresek. Nem vagyunk egy Google méretű cég.
Egy ilyen rendszerben
-Bármelyik kommithoz lehet hozzászólni (adott sorhoz, vagy az egészhez), miután megjelenik a központi repository-ban (pusholják).
-a javítás egy közönséges új kommitban érkezik be, és az előzőt nem bántja senki, ottmarad
-a kommit elfogadása, vagy el nem fogadása a tool-ban valójában jelképes. Az már bekerült a repository-ba.

Mégis lehet el nem fogadni, csak nem úgy. Például egy konkrét fejlesztést egyben review-olni úgy lehet ezzel a módszerrel, hogy egy külön ágon készül el -feature branch-. A teljes ágat lehet átnézni befésülés előtt vagy egyben, vagy akár folyamatában. Amíg nincs olyan állapotban -és ugye nincs határidő…-, egyszerűen nem kell befésülni.
A review nem blokkolja a munkafolyamatot. Ha nem csinálja meg senki, akkor is megy a projekt. Mint ahogy az egyébként a kis cégek jórészénél történik is.

A legismertebb példa az ilyen fajtájú review-ra a github-on van. De nem ingyenes magáncélra, nem nyílt forrású, túl sok mindent tud, és a workflow is bonyolultabb, mint cégen belülre kell. -pl. mindig forkolnia kéne mindenkinek ugyanazt a projectet

Tisztán csak review eszközt kerestem post-commit workflowra. Nem sok van.

Barkeep

Ezt mondja magáról:

barkeep_logo
“you can watch commits made to any Git repository, see diffs, write comments, and have those comments emailed to your fellow committers”

Hát pont ezt kerestem. Később azt is írja hogy könnyen hackelhető. Igaz is.
Sőt. Ha elkezded használni nagyon hamar azon kapod magad hogy már hackeled. Vagy valami nem működik, vagy csak nem úgy.

Viszonylag gond nélkül telepítettem, és elsőre egészen működni látszott.
Köszönt mikor a logora húztam az egeret, és már csak rá kellett bólintani: Ugye megtarthatom?

De hamar jöttek az első bugok. A magyar ékezetek UTF-8-al több helyen kiakasztották. Legsérülékenyebb a levélküldés volt. Így ismerkedtem meg a ruby-val.
Ruby-ban a default kódolása a stringeknek ASCII-8BIT. Legalábbis 2.0 -ig. Naná hogy 1.9-ban vagyunk. De nem ám olvashatatlan karakterek kerülnek a string-be, hanem kivétellel elszáll valamelyik stringművelet. Ez a működés a szintén ruby-ban írt Resque háttérfolyamat kezelővel együtt zseniális. A barkeep ezt használja. A Resque az error log-ba eltárolja a hibaüzenetet, de azt nem, hogy mi volt a stacktrace -ruby nyelven backtrace-. Így az se látszik milyen szöveggel volt a baj, és az se hogy hol jött a hiba.

Túljártam az eszén. Parancssorból indítva közvetlenül a levélküldő jobot már láttam a backtrace-t. Ki is hackelgettem. Sőt később még azt is megoldottam hogy logfile-ba kerüljenek ezek a backtrace-ek.

Ezen túl az email címek kezelését kellett felokosítani. A barkeep az autentikációhoz használt email cím segítségével köti össze, hogy ki melyik kommitot csinálta. És jelenleg egyetlen autentikációs módot támogat: google-n keresztül oauth.

Tehát ha a git commitok nem a gmail címeddel készülnek, akkor szívtad. Egyértelmű, hogy mindenkinek a céges email címe kerül a kommit-ba. A feature-t lefejleszettem, beküldtem.

Amit beküldtem hibajegyek, patch-ek, pull requestek:
https://github.com/ooyala/barkeep/issues/created_by/kumm?state=open

Amit már be sem küldtem a logolás:
https://github.com/kumm/barkeep/commit/008750141a07dd56375821f869f4bc8d113127fe

Keep-it-simple-stupid-banner-poster

És ezután már csak az volt hátra, hogy a céges smtp szerverrel tudjon a barkeep levelet küldeni. A fejlesztők nagyon komolyan vették a KISS -Keep It Simple Stupid- metodikát, így az egyetlen támogatott mód a gmail smtp. Erre szerencsére van el nem fogadott pull request. pull/379
Saját szakállamra befésültem, és meg is vagyunk.

Az eszköz tökéletesen működik több mint három hónapja. Tudja amire szükségem van, és azon kívül semmit. Jó hát, az utóbbi nem feltétlenül előny.

A projekt sajnos nem igazán pörög. Egy issue-ra sem jött érdemi válasz, és egy pull request-re sem regáltak. Az egyik megoldásomra összesen ennyit írt egy (volt?) fejlesztő: “Nice Find!”
De én is üdvözlöm őket az ooyala-nál, mert ennyi munkából nem lenne nélkülük review tool-om.

Aki szeretné nem angol szövegű emailekkel, nem gmail címekkel, nem gmail smtp-vel kipróbálni, itt megtalálja:
https://github.com/kumm/barkeep
-Semmi garancia, és telepítés után megsemmisíti magát.
-Vagy kicsit később.

Ha valaki meg tud barátkozni azzal a gondolattal, hogy a tool többet tud, próbálja ki a GitLab-ot, vagy a Gitorius-t. Mindkettő git szerver, issue tracker, wiki, meg még ez-az egyben. Amolyan github-light. Vagy esetleg a Phabricator-t, ami szintén sokat tud. Pár órát nézegettem ezeket is, de egy időre kiéltem magam a témában.

Share on FacebookShare on Google+Email this to someoneTweet about this on TwitterShare on RedditShare on LinkedIn

4 hozzászólás

Viczián István says:

2013. október 8. at 20:23

Becsülöm a kitartásod, én már az első próbálkozásnál feladtam volna, és másik után néztem volna.
Nálunk igényként jelentkezett az IDE integrálhatóság is. Nem tartod nehézkesnek, hogy egy webes rendszeren kell nyomulni, ahelyett, hogy az IDE-ből csinálnád?

Reply

Huba Zsolt says:

2013. október 11. at 19:47

Nálatok mi lett a választott eszköz?

Reply

Tamás Kimmel says:

2013. október 9. at 17:46

Az igény jogos, de lehet nélküle élni. Sokszor kell IDE is.
Nem látszik a konkrét commit-ban, az az osztály amit hivatkozik, vagy úgy általában a tágabb környezet.
Szép lenne az IDE integráltság, csak olyan nem jött szembe. Legalábbis azon kívül hogy hallottam valamit a gerrit Eclipse pluginról, de hát az kiesett, ráadásul netbeans-t használunk.
Végül sikerült ilyen IDE-s eszközt találni?

Reply

Huba Zsolt says:

2013. október 11. at 20:03

Ezt a kérdéskört már volt szerencsénk IRL kitárgyalni. Kb egyet is értek a leírtakkal.
Annyival egészíteném ki, hogy szerintem nem a projektméret, hanem a projekt jellege határozza meg a review eszközt.
Nálunk termékfejlesztésnél, ahol magas kódminőség volt a fontos, jól bevált. Csak kitesztelt, átnézett kódok kerültek be vele a főágba. Maga a fejlesztés sem volt olyan kapkodós, hogy ezt ne bírta volna ki.
Ugyanez az eszköz sokkal kevésbé hatékony egyedi fejlesztésű projektek esetén, ahol minden gyorsabban történik és a review folyamat megakasztja a workflow-t.
Mindkét verziót volt szerencsém kipróbálni 🙂

Reply

Leave a comment