Koukám, že už je to čtyři roky, co jsem se tu zamýšlel nad tím, že mi chybí code review. Od té doby jsem se já i náš obor trochu posunuli. Se Softwa­rovým Samurajem jsme používali branch-by-feature (i když už pak nedopsal, že jsme to později vylepšili o plugin hg-flow). K dokona­losti chybělo pár drobností. Dost věcí z code review checklistu jsme kontro­lo­vali manuálně, jako například formátování, pokrytí testy či postřehy, které by odhalila statická analýza kódu (PMD, FindBugs…). Je to otravné a vyčer­pávající, takže už se tolik nesou­středíte na věci jako design, logování atd. Navíc build běžel až nad develop větví, takže se mohlo stát, že jste sice krásně schválili pull request, ale ten po zamergování shodil build. Jak to vylepšit?

Jenkins a BitBucket

Pro Jenkins existuje Bitbucket Pull Request Builder Plugin. Díky němu si můžete nastavit build, který se spustí nad každým pull requestem v Bitbuc­ketu. Rovněž zkont­ro­luje statickou analýzu kódu (pokrytí testy, PMD, FindBugs, Check­s­tyle a dupli­city kódu), jejíž konfi­gu­rací se teď zabývat nebudu. Pokud jsou všechna pravidla splněna, tak pak pull request jako jakýkoliv jiný reviewer schválí.

Schválený pull request v Bitbucketu

Konfigurace

Používáte-li feature branche ve tvaru feature/bitcoint-payment, tak nastavíte masku na */${sourceBranch}. Vhodné je zapnout volbu Cancel outdated jobs, která zajistí to, že nový commit zruší již běžící build nad danou větví (zbytečně se tak nezatěžuje server). Může se stát, že build selže, přestože je kód v pořádku, třeba kvůli chybějící závis­losti v maven repository. V takovém případě do komen­táře pull requestu v Bitbuc­ketu napíšete to, co je nakonfi­gu­ro­vané v Comment phrase to trigger build a build se spustí znovu. V našem případě je to.

test this please

U statické analýzy můžete nastavit práh (počet porušení pravi­del), kdy má build selhat (červený) či se má označit za nesta­bilní (žlutý). V ideálním případě by to měla být nula, ale to se ne vždy daří. Buď máte pravidla, která nedod­ržu­jete, a pak by stálo za to je zrevi­do­vat, nebo pracu­jete s legacy kódem, který sice zlepšu­jete, ale po malých krůčcích. Jenkins porov­nává počet nových chyb vůči předchozímu buildu, což nemusí vždy být ta samá feature branch. V takovém případě se může stát, že opravíte jednu chybu, ovšem zavlečete jinou, přesto čísla zůstanou stejná. A to mi přijde škoda.

Nasta­vení prahu pro Checkstyle

Jako vylepšení můžete nakonfi­gu­ro­vat, že se má Jenkins před buildem pokusit o lokální merge, který se nedostane do remote repository. To pomůže zavčasu odhalit nekon­zis­tenci mezi zdrojovou a cílovou větví.

Plugin nemá podporu webhook, takže se build spouští přes klasický cron trigger (aktivní čekání).

Existuje Viola­tion Comments to Bitbucket Server Plugin, který umí vkládat komen­táře do pull requestu přímo ke kódu, ale funguje jen pro standa­lone Bitbucket Server. Nicméně dá se žít i bez něj, prostě se proklik­nete na daný build a chyby si dohledáte na Jenkinsu.

Jenkins a GitHub

Pocho­pi­telně se někteří budou ptát, jak je to s podporou GitHubu. Osobně nemám vyzkoušené, ale očekávám, že postup bude analo­gický. Podělte se o své zkuše­nosti v komen­táři pod článkem. Můžete se podívat třeba na GitHub pull request builder plugin

Pár poznámek k Gitu

Pokud používáte feature branche, určitě jste v historii Gitu viděli spoustu čar, kterým mnozí říkají „nádraží“, a někdy není přehledné zjistit odkud kam vedou. Osobně rád často commituju svoje meziřešení, abych měl stabilní kroky, ke kterým se můžu vracet, čímž čáry prodlužuju. Pro potřeby code review to nevadí, ale před finálním mergem do develop větve takzvaně squashnu: sloučím všechny commity do jednoho (výji­mečně do více, má-li to význam držet v historii). K tomu používám inter­ak­tivní rebase.

git rebase -i develop

Nakonec v remote repository musíte přepsat historii pomocí

git push --force-with-lease

Závěr

Bez pull request verifieru bych si už svoje workflow nedokázal předs­ta­vit. Programátor dostane včas zpětnou vazbu a reviewer, kterého jsme tímto pluginem rozhodně nechtěli nahra­dit, má víc prostoru prozkoumat ty aspekty, které ještě neumíme zautomatizovat.

Související