Vrátil jsem se nedávno k jedné odložené aplikaci a začínám ji křísit s novými nápady a s trochu změněným konceptem (s detaily přijdu v brzké budoucnosti) a protože jsem se dostal k potřebě aplikaci testovat ve více lidech, kdy někteří mají ne zrovna aktuální verzi buildu a přesto reportují chyby, začal jsem používat systém číslování verzí, který bych chtěl tímto postem popsat.

Problém je následující: vypustím testovací verzi mezi testery a mezitím vývoj nezamrznu, ale pokračuju v opravách, úpravách a (přiznám se k tomu) někdy i nových featurách. Často se stane, že tester pošle stacktrace starší verze, nebo přijde aktuální verze, jenomže po úpravách už nesedí čísla řádků, či díky refactoru je daný fragment někde úplně jinde a podobně. Jak teda zkontrolovat, jestli už chyba byla odstraněna, nebo tam je pořád? Poměrně jednoduše, stačí pár nástrojů.

Celý řetězec sestává z IDE Eclipse, Pivotal Trackeru, PT-mylyn connectoru a nějakého systému zprávy verzí (používám Git na Bitbucketu). Základem je si navyknout odklepávat aktivní tasky zadané pomocí Pivotal Trackeru v Mylynu, měnit odpovídající čísla patchů v Manifestu a commity provádět s daným identifikátorem (ideálně do vlastního branche, který se po release zmerguje, ale kdo by se s tím sr…l, žejo :)). Pojďme ale postupně, ukážu to na konkrétním příkladě – tasku. (Pozn. používaná skladba číslování verzí vychází z následujícího schématu, uvedeného např. na wikipedii).

Veškeré změny, požadavky a bugy zadávám pouze skrze Pivotal Tracker (nebudu tu rozebírat nástroj samotný, ani jak iteruju – to je každého věc :)). Důležité je, že každá story má jednoznačný identifikátor, jak je vidět na následujícím screenshotu.

V Eclipse mám PT napojený skrze mylyn-connector (návod jak na to je přímo na stránkách projektu) na Task list, kdy pracuju na aktuální vybrané úloze. Na následujícím screenshotu už je story finishnutá, takže je přeškrtnutá.

Když potom dané změny commitnu, nechávám jako title dané změny identifikátor a popisek, který je v PT – při commitu jsou už automaticky předvyplněné. V přehledu verzovadla je potom jednak vidět interní identifikátor daného commitu, ale v rámci popisku i identifikátor z PT.

A teď ono celkové propojení: když aktivuju task v IDE, změním daným identifikátorem z PT i build verzi v manifestu, společně s versionCode.

Když tedy následně distribuuju danou verzi testerům, tak je možné v rámci vlastností aplikace přehledně zkontrolovat verzi, kterou testují.

A pokud někdo nahlásí chybu, o které si nejsem jistý, zda byla opravená, jednoduše se vrátím ke konkrétní verzi z repozitáře a můžu zkontrolovat, o co vlastně šlo a případně si zadat novou story (bug by mohl být zadán číslem revize a build verze se neměnit).

Je mi jasné, že asi znovuobjevuju kolo, ale připadlo mi to celé tak geniálně jednoduché a praktické, že mi nedalo se o to nepodělit. Také mi nedá se nepodělit o očekávání testovacího frameworku Testflight pro Android. Věřím, že předchozí tipy skvěle doplní a posune na ještě vyšší level!