Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky
Bakalářská práce
Vylepšení správy chyb v systému Flyspray
Plzeň, 2010
Jan Rybák
Prohlášení Prohlašuji, že jsem bakalářskou práci vypracoval samostatně a výhradně s použitím citovaných pramenů.
V Plzni dne 13. května 2010 ................................................... Jan Rybák
1
Poděkování Děkuji Ing. MSc. Přemyslu Bradovi, Ph.D. za odborné vedení mé bakalářské práce.
2
Abstract Improvement of bug tracking in Flyspray system
3
Obsah 1 Úvod
5
2 Správa chyb a požadavků 2.1 Vývoj softwaru . . . . . . . . . . . . . 2.2 Chyby v softwaru . . . . . . . . . . . . 2.3 Bug tracking . . . . . . . . . . . . . . . 2.4 Systémy pro správu chyb a požadavků 2.5 Porovnání open-source bugtrackerů . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
6 6 7 8 13 15
3 Aktuální stav systému Flyspray 17 3.1 Základní informace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2 Programátorská dokumentace . . . . . . . . . . . . . . . . . . . . . . . . . 18 4 Analýza nedostatků systému Flyspray 4.1 Využití systému Flyspray v rámci ZČU 4.2 Hromadná editace úkolů . . . . . . . . 4.3 Integrace se systémem správy revizí . . 4.4 Statistiky a časový management . . . . 4.5 Integrace s wiki . . . . . . . . . . . . . 4.6 Použitelnost UI . . . . . . . . . . . . . 5 Realizační část 5.1 Hromadná editace úkolů . . . . . . . 5.2 Vytvoření odkazu na SVN repozitář . 5.3 Vytvoření odkazu na SVN changeset 5.4 Úprava API pro použití s úložištěm . 5.5 Instalační balíček . . . . . . . . . . . 5.6 Testování . . . . . . . . . . . . . . . 5.7 Možná vylepšení . . . . . . . . . . . 5.8 Zveřejnění . . . . . . . . . . . . . . . 6 Závěr
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
. . . . . . . .
. . . . . .
23 23 23 24 25 26 26
. . . . . . . .
27 27 30 31 32 33 34 34 35 36
4
1
Úvod
5
2
Správa chyb a požadavků
2.1
Vývoj softwaru
Humphrey [1] popisuje proces vývoje softwaru jako sadu nástrojů, metod a praktik, které využíváme k tvorbě softwarového produktu. Oblast informačních technologií je specifická obrovským tempem pokroku, a proto se zmíněné prvky velice rychle mění. Vývoj softwaru už dávno neznamená pouze psaní zdrojového kódu a následnou kompilaci ve výsledný program. Jedná se o komplexní problematiku, která zahrnuje mnoho dalších aktivit, z nichž některé na první pohled ne zcela souvisejí s informačními technologiemi. Aby vznikl nový produkt, musí celý proces vývoje projít stádiem plánování, implementace, testování, dokumentace, nasazení a údržby. Ovšem ani dokonalý produkt sám o sobě není zárukou úspěchu, je nutné zajistit i odpovídající marketing, údržbu a v neposlední řadě i podporu cílovým zákazníkům. Jelikož na softwarových projektech ve většině případů spolupracuje více lidí, týmů a často i firem, je nezbytně nutná kvalitní komunikace a koordinace týmů i každého jedince. Když k tomu připočteme složitost vývoje, je evidentní, že k usnadnění project managementu musely být navrženy metodiky a systémy zajišťující jejich správnou aplikaci. V současnosti mezi nejvyužívanější vývojové postupy patří iterativní a agilní metodiky jako například extrémní programování (XP1 ), Scrum či RUP. Od dříve navržených metodik, mezi něž můžeme zařadit vodopádový a spirálový model, se kvůli jejich malé flexibilnosti pomalu ustupuje nebo dochází k jejich obměně. Softwarové nástroje používané ke správě projektů se označují jako project management software a zahrnují programy určené k plánování (scheduling), správě nákladů (budget management), konfiguračnímu managementu (SCM), týmové spolupráci (collaboration software), řízení kvality (QA) apod. Do posledně uvedené kategorie spadají i aplikace určené ke sledování hlášených softwarových chyb (bug tracking), o kterých pojednává moje práce. Úspěšnost softwarových projektů Podle společnosti Datamonitor [2] dosáhl trh se softwarem v roce 2008 hodnoty 303.8 miliard amerických dolarů a předpověď na rok 2013 se pohybuje kolem 457 miliard USD. Zároveň však z průzkumu společnosti Standish Group [3] nazvaném CHAOS Summary 2009 [4] vyplývá, že v roce 2009 pouze 32% projektů bylo dokončeno včas, v předpokládaném rozpočtu a splňovalo očekávání zákazníků. Dalších 44% projektů bylo sice dodáno, ale jeden či více z výše uvedených závazků nebyl splněn a zbylých 24% projektů bylo ukončeno již v průběhu vývoje nebo nebylo nikdy nasazeno do provozu. Ze statistiky jsou na první pohled zřejmé enormní finanční ztráty způsobené převážně špatnou správou projektů. 1
Seznam všech používaných zkratek je uveden na konci dokumentu.
6
2.2
Chyby v softwaru
Dělat chyby je lidské a protože programátoři jsou lidé, chyby k softwaru patří. Debugging, nebo-li odstraňování chyb, je nedílnou součástí vývoje softwaru už od počátku počítačové éry a bylo vynaloženo velké úsilí při pokusech o vytvoření nástrojů a metodik, které by zamezily jejich vzniku. Častěji než dříve na počítačích závisejí kritické oblasti lidského života a historie zaznamenala případy, kdy kvůli chybě v počítačovém programu zemřeli lidé [5] nebo byl zničen majetek velké hodnoty [6]. V roce 2002 zveřejnil americký National Institute of Standards and Technology [7] zprávu [8], že téměř 60 miliard USD je v USA ročně investováno do oprav a testování softwarových chyb, přičemž by za použití adekvátních nástrojů bylo teoriticky možné tuto sumu o třetinu snížit. Anketa, která byla součástí zprávy, mimo jiné prozradila průměrné náklady spojené s jednou chybou v komerčním softwaru a ty činily 3 292 USD, odložení vydání produktu o 1,5 měsíce a průměrnou dobu opravy jedné chyby 18,6 hodin. Dotazované firmy uvedly, že chyby v jejich produktech způsobily zpoždění dodání produktu oproti smluvním termínům, ztrátu reputace a některé kvůli chybám ztratily podíl na trhu. Definice softwarové chyby Chyba v softwaru, často též označována jako „bug”, „issue”, „problem”, „defect” nebo „error”, je nesprávné chování určité části nebo přímo celého systému. Za nesprávné chování považujeme nechtěnou reakci systému nebo naopak špatně prováděnou reakci, kterou vyžadujeme. Tento jev je ve většině případů způsoben lidským faktorem a jeho příčinou může být nevhodný návrh systému, chyba ve zdrojovém kódu nebo neošetření některých stavů, které mohou nastat. Výskyt chyb Každý vývoj softwaru, ať už se jedná o úplně nový projekt, či práci na již hotovém produktu, s sebou přináší riziko vzniku chyb. Přes veškeré snažení vývojářů a testerů není možné výskytu chyb předejít a je tedy otázkou, jak množství chyb kontrolovat a snížit na potřebné minimum. Počet nově vznikajících chyb není v průběhu vývoje softwaru konstantní a ani náklady spojené s opravou nejsou stejné na začátku vývoje a na konci. Chyba může vzniknout v jakékoliv fázi vývoje, ale nemusí být okamžitě detekována. Obecně se dá tvrdit, že čím déle chyba v systému existuje, tím problematičtější bude její oprava. Ve fázi testování je typicky nárůst nově objevených chyb nejmarkantnější, což je patrné na obrázku. Obrázek 1: TODO: Nárůst počtu objevených chyb. Náklady na opravu chyb se s postupným vývojem rapidně zvyšují. Uvádí se, že cena opravy chyby na konci vývoje (ve fázi vydání produktu) dosahuje třiceti- až stopadesátinásobku ceny opravy ve fázi návrhu softwaru (viz graf). 7
Obrázek 2: Cena opravy chyb se v různých projektech liší, ale vždy s časem stoupá. Opravování chyb Ačkoliv by se mohlo zdát, že opravení každé zjištěné chyby je samozřejmá volba, není tomu tak. Mohou nastat situace, kdy oprava za každou cenu není nejvýhodnější řešení. Jak už bylo zmíněno, vývoj softwaru je obrovský business a to je nutné brát v úvahu při opravování chyb. Každá oprava zabere určitý čas a lidské zdroje. Úsilí vynaložené na opravu chyby je možné finančně vyčíslit a tím pádem se volba, zda chybu odstranit či ne, stává manažerským rozhodnutím, nikoliv programátorským. Existují ovšem kritické oblasti, kde je „komfort” úmyslného neopravování chyb nemyslitelný - např. letecký průmysl nebo zdravotnictví.
2.3
Bug tracking
Bug tracking (BT), někdy také issue tracking, je jedna z důležitých aktivit projektového managementu, konkrétně spadající do oblasti tzv. problem managementu. Jedná se o hlášení a sledování chyb v softwaru, jejich třídění a vyhodnocování. Primárním cílem bugtrackerů2 je vytvoření centralizovaného přehledu vývojových požadavků, ať už se jedná o chybová hlášení (bug reports) nebo o požadavky na vylepšení (feature requests) [9]. Bug reporty nebo feature requesty, někdy souhrně označované jako tickety, jsou prostřednictvím formuláře vkládány do systému a je možné s nimi dále pracovat. Bugtracker můžeme chápat jako komunikační nástroj, který slouží k přenosu informací o chybách a požadavcích mezi testery3 a vývojáři, zároveň udržuje informovanost projektových manažerů a často mezi jeho funkce patří i sběr požadavků a hlášení problémů od uživatelů. Možnosti využití bugtrackingu Funkce bug trackingového systému (BTS) se může v různých firmách měnit. Dokonce se jeho využití může lišit v různých fázích vývoje na jednom projektu. Původní smysl takového systému byl prostý - zaznamenání nalezené chyby v programu. Pokud se chyba 2 3
Bug trackingové systémy. Člověk zabývající se testováním softwaru.
8
nezapíše v okamžiku jejího nalezení, zapomene se na ni. K účelu záznamu mohla dříve dobře posloužit i tabule v kanceláři vývojářů. Nyní ale mnoho týmů spolupracuje na dálku a tak se BT systémy vyvinuly přes e-mailové konference a diskusní fóra až k aplikacím určeným výhradně pro tyto účely. V článku [10] se Adam Kolawa zamýšlí nad využitím bugtrackeru v počátku vývojového procesu při volbě metodiky extrémního programování. Protože bezchybnost kódu je podle něho v tuto dobu zajištěna unit testováním4 , je vhodné do BTS vkládat návrhy na změny a nové funkce. V okamžiku spuštění beta-testingu5 dojde k „zamrazení” kódu a nejsou již přijímány návrhy na změny, namísto nich se do BTS konečně vnáší chybová hlášení. Další možností, jak použít BTS, je reportování chyb a požadavků samotnými uživateli. Tento trend je možné často spatřit u open source6 aplikací, jako jsou například produkty společnosti Mozilla7 nebo databázový systém MySQL8 . Na webových stránkách projektu bývá sekce, kde uživatel vyplní a odešle formulář s popisem chyby. Aby byla tato aktivita přínosná, je nutné dodržení základních zásad a etiky při zadávání dat (viz níže). Význam bugtrackingu Není sporu o užitečnosti, dalo by se říci až nezbytnosti, BTS při zaznamenávání informací o chybách. Rád bych ale nastínil jěště další možný přínos, který tento systém společnostem poskytuje. Bug trackingový systém je vlastně databáze chyb a návrhů včetně doplňujících informací o jejich stavu, závažnosti, řešení apod. Množství shromažďovaných dat závisí na složitosti, případně nastavení konkrétního BTS. Reporty v databázi zůstávají i po uzavření (vyřešení) a tím uchovávají cennou historii komunikace, resp. provedené práce na opravách softwaru. I když to na první pohled nemusí být zřejmé, správným používáním bugtrackeru zároveň generujeme znalostní bázi (knowledge base) řešených problémů a při opětovném výskytu problému v budoucnu již máme k dispozici informace o řešení. BTS může výrazně šetřit čas a práci, zároveň napomáhá vyvarování se stejným chybám. BTS slouží jako zdroj mnoha statistik týkajících se kvality softwaru (SQA) a může napovědět mnoho o úskalích programu a někdy i lidech. Většinou existuje možnost rozlišovat verze produktu, kterým bug reporty náleží. Není proto nijak složité porovnávat chybovost libovolných vydání (release) produktu a z porovnání vyvozovat závěry. Pomocí zařazení bug reportů do katagorií získáme přehled o počtu chyb v jednotlivých částech produktu. Spadá-li například 80% všech reportů do kategorie ’GUI’, nabízí se otázka, zda nezvážit úplné předělání grafického prostředí programu, protože generuje většinu problémů. Lze analyzovat časové informace, např. průměrnou dobu opravy jedné chyby, průměrnou 4
Technika testování softwaru pomocí dílčích testů pro každou jednotku kódu. Po uvolnění beta-verze produktu, se na testování podílejí sami uživatelé. 6 Počítačový software s otevřeným zdrojovým kódem. 7 Mozilla Corporation. 8 MySQL vlastněný firmou Sun Microsystems. 5
9
dobu čekání bug reportu na reakci vývojářů, průměrné doby opravy chyb jednotlivými vývojáři atd. A v neposlední řadě ze statistik můžeme vyčíst informace o pracovnících. Tester, který odhaluje převážně kritické chyby, je pravděpodobně užitečnější než tester, jehož bug reporty se objevují denně, ale mají téměř vždy nastavenou nízkou závažnost chyby. Mnoho znovu-otevřených reportů zase svědčí o nedůsledném programátorovi. Pokud se na problematiku podíváme z hlediska uživatele, jsou BTS nejjednodušší a nejúčinnější formou nahlášení problému, případně požadavku vývojářskému týmu. Je velice častým jevem, že chyba, kterou chce uživatel nahlásit, se už někdy vyskytla u jiného uživatele a dost možná se ji podařilo vyřešit. V takovém případě je řešení relativně rychle nalezeno. Pokud je uživatel prvním, kdo chybu zaregistroval, stačí správně9 vyplnit formulář BTS a čekat na odpověď. Pro vývojáře produktu je zpětná reakce v podobě uživatelských návrhů a problémů velice cenná. Pro uživatele je fungující podpora ukazatelem solidní vývojářské společnosti. Bug report / feature request Jedná se o strukturovaný dokument, přesně popisující chybu (požadavek) v softwaru. Vytvářet ho mohou vývojáři, testeři nebo uživatelé. Při psaní reportu by měla být dodržena určitá pravidla, která popisuji v následující kapitole.
Obrázek 3: Ukázka bug reportu v systému Flyspray 9
Metody správného vyplnění bug reportu jsou řešeny v kapitole „Zásady bugtrackingu”.
10
Zásady bugtrackingu Stejně jako existují správné zásady přispívání do internetových diskusních fór10 , je užitečné dodržovat pravidla pro hlášení chyb v bugtrackeru. Efektivní hlášení chyb může výrazně zvýšit šanci na opravu chyby, protože vede k dobrému porozumění problému programátory a zbytečně neplýtvá jejich časem. Ještě před samotným napsáním bug reportu se doporučuje provést několik základních kroků (ad1, ad2, ad3). 1. Pravidla a pokyny BTS Každý BTS může mít upravená pravidla hlášení a používání systému podle svých potřeb. Je vhodné si je přečíst. 2. Upgrade Pokud existuje novější verze používaného programu a nic nebrání upgradu, je vhodné přejít na poslední verzi produktu. Je pravděpodobné, že v nové verzi je chyba odstraněna. Každý BTS může mít upravená pravidla hlášení a používání systému podle svých potřeb. Je vhodné si je přečíst. 3. Vyhledání stejného problému Jak už bylo řečeno, málokdy je uživatel první, kdo na problém narazil. Vyplatí se důkladně prohledat archiv bug reportů a pátrat po stejném či podobném problému. Mohou nastat následující tři situace: • problém je v BTS a je již vyřešen - uživatel našel, co chtěl • problém je v BTS a není vyřešen - o chybě se ví, není důvod duplikovat bug report • problém není v BTS - uživatel může vytvořit nový bug report 4. Přesnost a kompletnost údajů při zadávání reportu Nejasnosti jsou zdrojem omylů a nedorozumění. Formulář chybového hlášení by proto uživatel měl přesně a důkladně vyplnit. Je lépe sdělit více informací než méně, ale vždy konkrétně a jasně. V reportu je důležité uvést: • titulek - měl by být výstižný, konkrétní, jednoznačně charakterizovat chybu • popis problému - jak se projevuje, kdy se projevuje • reprodukce - přímočarý postup jak chybu vyvolat • prostředí a nastavení systému, ve kterém problém nastal • verzi produktu - včetně instalovaných rozšíření, verzí knihoven atd. • reálnou reakci programu - jak program ve skutečnosti reaguje • očekávanou reakci programu - jak by podle uživatele měl reagovat 10
Například zde: http://www.mozilla.org/community/etiquette.html.
11
• příloha - např. logovací soubor, vstup/výstup z programu, screenshoty11 apod. 5. V jednom reportu pouze jeden problém Je důležité toto pravidlo dodržovat, aby se s tickety (reporty) dobře pracovalo. Každá chyba může spadat pod jiného programátora a v případě uvedení více chyb by nebylo možné práci rozdělit. 6. Reprodukce chyby Pokud programátor nemůže chybu reprodukovat, pravděpodobně ji nebude moct ani opravit. Je tedy nezbytné poskytnout všechny informace užitečné k vyvolání chyby. Životní cyklus bug reportu Existuje základní schéma životního cyklu bug reportu (viz obrázek 4). V některých systémech může být pozměněno nastavením tzv. workflow. Tyto úpravy se většinou týkají rozdělení uživatelských rolí opravňujících k vykonání určité akce či přechodu do určitého stavu. V některých společnostech není kvůli kontrole každému umožněno měnit stavy bug reportu. Otevření nového bug reportu tak může předcházet návrh na otevření a až po schválení, zda se opravdu jedná o (novou) chybu, dojde k zanesení reportu do BTS. Podobně programátor po vykonání opravy pouze označí chybu jako vyřešenou (resolved), ale uzavření ticketu spadá do kompetence testera, který nejprve důkladně otestuje bezchybnost programu.
Tabulka 1: Tabulka základních stavů bug reportu
11
NEW
Nový bug report je zadán do BTS.
ASSIGNED
Vyřešení chyby je někomu zadáno (asignee).
RESOLVED
Problém je označen jako vyřešený.
VERIFIED
Řešení je potvrzeno jako správné.
REOPEN
Bug report je znovu otevřen z důvodu přetrvávajících problémů.
CLOSED
Bug report je uzavřen, chyba je opravena.
Snímek počítačové obrazovky.
12
Obrázek 4: Životní cyklus bug reportu.
2.4
Systémy pro správu chyb a požadavků
Systémy pro správu chyb a požadavků, označované jako bug tracking, případně issue tracking systémy, se vyvinuly z potřeby vzniku specializovaného softwaru nabízejícího pokročilé funkce pro práci s bug reporty. Pro představu mezi tyto funkce můžeme zařadit např. přiřazení ticketu kompetentní osobě, nastavení aktuálního stavu ticketu atp. Často můžeme bug tracking systémy vidět jako integrovanou součást komplexního systému pro správu projektu, který zároveň nabízí další nástroje jako ticketing (přiřazení úkolů uživatelům), time management nástroje (milníky, time tracking), collaboration nástroje (wiki, chat, fórum), hosting verzovacích systémů (Git, SVN) a podobně. Bug tracker je specializovaná verze ticketing systému, takže využití systémů se zabudovanou podporou ticketů je možné a vhodné. Vlastnosti bugtrackerů • Práce s ticketem Práce s ticketem je základní vlastností BTS. Většina systémů umožňuje následující akce: – změna stavu ticketu (vytvoření, přiřazení, uzavření, znovu-otevření) – editace položek
13
– sledování - uživatel je upozorňován na změny – vytvoření závislosti na jiném ticketu – komentování • Uživatelské účty BTS musí podporovat více uživatelů a proto má každý uživatel svůj účet. Účty se sdružují do kategorií (skupin) uživatelů, které se liší poskytnutými právy. • Uživatelské rozhraní Práce s BTS by měla být především rychlá a intuitivní. Tomu je často podřízen vzhled (Flyspray, Trac, Bugzilla). Na první pohled by měly být rozlišitelné závažné bug reporty od těch méně závažných, bývá zvykem že jsou odlišeny podbarvením (barvy teploměru: modrá..červená). Práci urychluje propojení různých částí systémů pomocí odkazů - např. použitím klíčového slova a id bug reportu v popisku jiného bug reportu vznikne odkaz. Podpora jazykových lokalizací může být pro některé společnosti kritériem výběru toho konkrétního BTS. • Možnosti nastavení Uživatelská nastavení přizpůsobují chování BTS potřebám project managerů a vývojářů. – Konfigurace uživatelských práv je důležitá, především obsahuje-li bug tracker více projektů nebo je-li v rámci projektu angažováno více lidí s různými rolemi. Řízení správy chyb je pod lepší kontrolou. – Nastavení workflow úzce souvisí s nastavením uživatelských práv (viz příklad, že programátor nemůže sám uzavřít ticket). V robustních systémech může být workflow provázáno i s vývojovým prostředím. – Uživatelsky definovatelné položky rozšiřují možnosti využití BTS a jejich přizpůsobení konkrétním potřebám. – Notifikace je další užitečná možnost. Ve většině systémů lze nakonfigurovat upozornění určitých uživatelů o určitých událostech. Existuje více možností, ale většinou se k oznámení využívá e-mail (FS nabízí Jabber). • Vyhledávání Kvalitní vyhledávání je nedocenitelná pomůcka při správě většího množství ticketů. K nalezení bývá využíváno id bug reportu, ale zároveň bývá k dispozici pokročilé vyhledávání s filtry (omezení výběru na určitou podmnožinu). TODO: obrázek vyhledávání
14
• Integrace se systémem správy verzí Chyby v softwaru nejčastěji souvisejí se zdrojovými kódy, proto bývá propojení s verzovacími systémy často dostupnou funkcí. Nejpoužívanější verzovací systémy jsou Subversion (SVN), Mercurial, CVS a Git. • Statistické výstupy Numerické, případně grafické vyjádření dat o bug reportech - např. počty otevřených/uzavřených ticketů, množství provedené/zbývající práce,... • Export dat Export dat z databáze bývá realizován do formátů XML, CSV, iCal. • API API zajišťuje vzdálené ovládání - např. přidání ticketu, vložení komentáře nebo uzavření ticketu. Je vhodné především u web-based bugtrackerů. Typy bugtrackerů • Web-based systémy Mnoho programů v posledních letech převzalo podobu webové aplikace a oblast správy projektů není výjimkou. Webové systémy mají výhodu snadné instalace, přístupu prostřednictvím prohlížeče odkukoliv a rychlejšího vývoje. Často je bugtracker součástí rozsáhlejšího project management systému. Webová varianta je ideální volbou pro uživatelský BTS k účelu zákaznické podpory. Data jsou vetšinou uchována v nejvíce podporovaných databázích MySQL nebo PostgreSQL, existují BTS, které data ukládají v podobě XML souborů. V nabídce jsou placená i volně dostupná řešení. • Klientské systémy Jedná se o robustnější systémy než jsou webová řešení. Jejich výhoda může spočívat v propojení s vývojovým prostředím a lepší konfigurovatelností. Nevýhodou bývá vysoká cena.
2.5
Porovnání open-source bugtrackerů
TODO: doplnit srovnání os-BTS Kritéria srovnávání • instalace / údržba • GUI, intuitivnost, jazykové mutace (možnost překladu) • funkce 15
• možnost nastavení workflow • nastavení práv, rolí uživatelů • vyhledávání • integrace s verzovacími systémy • vizualizace, vyhodnocení, statistiky • možnosti rozšíření / adaptace na jiný druh systému (nejen sw) • notifikace • api • zabezpečení
Flyspray Assambla Trac Bugzilla Redmine
16
3
Aktuální stav systému Flyspray
3.1
Základní informace
Systém Flyspray byl jako mnoho dalších bugtrackerů vytvořen pro jeden konkrétní projekt a následně poskytnut jako open source řešení. Tony Collins, autor systému, potřeboval bugtracker pro webové stránky aplikace Psi Jabber Client, ale ostatní bugtrackery neodpovídaly jeho požadavkům. Aktuálně se vývoji Flyspraye nevěnuje a štafetu po něm převzal Florian Schmitz. Dalším aktivním vývojářem je Cristian Rodriguez. Ačkoliv je Flyspray užitečný software a zdá se, že ho používá mnoho uživatelů, současný vývoj se téměř nehýbe. Poslední stabilní verze (Flyspray 0.9.9.6) byla vydána 1. května 2009, tedy před více než rokem. Zároveň je k dispozici vývojová verze Flyspray 1.0.0dev, kterou je možné stáhnout na webových stránkách projektu v sekci ’development’12 nebo z SVN úložiště. Důvodem pomalého vývoje je pravděpodobně nedostatek financí - Flyspray je poskytován ke stažení zdarma a neobsahuje žádnou reklamu, ze které by vydělával. Jediným zdrojem peněz jsou finanční dary od uživatelů posílané prostřednictvím služby PayPal13 . Webové stránky Webové stránky jsou umístěny na adrese http://www.flyspray.org/. Poskytují informace o funkcích a systémových požadavcích, vývojářském týmu, nabízejí možnost stažení stabilní verze a poslední vývojové verze, je zde odkaz na demo, odkaz na bug trackingový systém samotného projektu Flyspray, uživatelskou dokumentaci a informace pro vývojáře. Jako tvůrce webů mám ke stránkám několik výhrad. Ačkoliv se každý může podívat na demo, bylo by užitečné v popisu systému poskytnout několik screenshotů aplikace za běhu včetně popisků. Web je obecně dost nepřehledný, některé odkazy může být těžké najít a funkce vyhledávání vrací uživatelsky nepřívětivou směsici textu. Celkově se o dokumentaci k systému Flyspray dá říct, že je nedostačující a to platí jak pro uživatelskou, tak i programátorskou (vůbec neexistuje). Důležité adresy:
12 13
Domovská stránka
http://www.flyspray.org/
Demo
http://www.flyspray.org/demo/
Diskusní fórum
http://forum.flyspray.org/
BTS
http://bugs.flyspray.org/
Flyspray na Google Groups
http://groups.google.com/group/flyspray
SVN úložiště
http://flyspray.svn.sourceforge.net/
URL: http://www.flyspray.org/development/ On-line platební systém.
17
Verze 1.0.0dev Z verze 1.0.0dev jsem vycházel při implementaci nových funkcí. Ačkoliv je tato verze ve stádiu vývoje, vybral jsem ji jako základ, protože obsahuje některá důležitá vylepšení. Na univerzitě se aktuálně používá verze 0.9.9.5.1, musel jsem tedy vyřešit přechod z této verze na novou, což se ukázalo jako nečekaný problém. Verzi 1.0.0dev nelze instalovat jako tzv. čistou instalaci, lze ji použít pouze jako upgrade nižších verzí. TODO: výpis problému při instalaci První problém - PHP 5.3.0 a vyšší. Další problém - nastavení v DB. Podpora Řešení problémů ve Flysprayi je nejlepší hledat na adrese http://bugs.flyspray.org/. Je to adresa BTS a některé chyby jsou již vyřešené a uzavřené. Žádné patche pro Flyspray nevycházejí, takže co nevyřeší sami uživatelé, zůstává nadále nevyřešené.
3.2
Programátorská dokumentace
Programátorská dokumentace k systému Flyspray buhužel není k dispozici. Abych byl schopen korektně realizovat úpravy funkčnosti systému, musel jsem pochopit, jak celý program funguje. Z toho důvodu jsem byl nucen pročíst všechny zdrojové kódy, prostudovat databázový model a vytvořit vlastní zjednodušenou dokumentaci. Technologie Flyspray je webová aplikace, tudíž jejím klientem je libovolný webový prohlížeč, doporučené jsou Mozilla Firefox a Opera. Je napsán ve skriptovacím jazyce PHP5. Jazyk PHP se využívá k vytváření dynamických webových stránek, protože PHP skripty jsou lehce slučitelné se zdrojovými kódy značkovacích jazyků (HTML, XHTML, XML apod.). Jazyk PHP je interpretován na straně serveru, je tedy nezbytný server s podporou PHP, např. Apache, lighttpd nebo IIS Web Server. Prezentační vrstva je vytvořena pomocí šablon s příponou ’.tpl’ a vyhovuje standardu XHTML 1.0 Strict s využitím kaskádových stylů (CSS). Podpora XML je vyžadována pro instalaci a fungování Jabberu14 . Zdrojové soubory jsou uloženy v kódování UTF-8. Některá data generovaná systémem Flyspray jsou uložena v souborovém systému např. konfigurační soubor, dočasná data (cache), ale převážná část se ukládá do SŘBD. Z databázových systémů jsou podporována dvě open source řešení - MySQL verze 4.x a vyšší a PostgreSQL verze 8.x a vyšší. 14
Komunikační protokol postavený na základě XML. Dnes přejmenován na XMPP.
18
Obrázek 5: Architektura a technologie Architektura Systém Flyspray je naprogramován podle principů MVC architektury. V praxi to znamená, že data jsou uložena v databázi, operace s nimi zajišťují PHP skripty a výstup je zobrazován pomocí šablon.
Obrázek 6: MVC architektura Třídy jsou uloženy ve složce includes, skripty ve složce scripts a šablony ve složce templates.
19
Obrázek 7: Adresářová struktura Databáze K práci s databází slouží funkce uložené v souboru class.Database.php. Tyto funkce využívají k databázovým operacím balíček PEAR::MDB2, což je abstrahující vrstva poskytující API k mnoha databázím (MySQL, PostgreSQL, Oracle, MSSQL, SQLite,...). Výhodou této vrstvy je objektové API a jednotná i jednoduchá manipulace s DB. Seznam databázových tabulek s popisem uložených dat je uveden v příloze. Třídy Kód systému Flyspray je řešen pomocí objektů. Každý objekt je reprezentován třídou (class). TODO: popis tříd • class Backend • class CommandExecution • class Field • class Flyspray • class FlysprayAuth, class LDAPAuth • class FlySprayCommand • class FlysprayDo • class FlySprayResponse • GPC classes 20
• class Jabber • class Notifications • class Project • class SVNInfo • class SyntaxPlugin • class TextFormatter • class Tpl, class FSTpl, • class User Šablony Výstup na obrazovku je řešen výhradně pomocí šablon. Šablony je možné skládat do větších celků prostřednictvím funkce pushTpl() třídy FSTpl, která dědí třídu Tpl. Tato funkce ukládá jednotlivé šablony do pole a zavoláním funkce finish() jsou všechny vykresleny na obrazovku. Pro upřesnění, funkce finish() volá funkci render(), která prochází pole s uloženými šablonami a každou šablonu pomocí funkce display() zobrazí. Příklad vykreslení pomocí šablony včetně nastavení titulku stránky, tématu a přiřazení proměnné: $page =& new FSTpl (); $page - > setTitle ( $fs - > prefs [ ’ page_title ’ ]. $proj - > prefs [ ’ project_title ’ ]); $page - > setTheme ( $proj - > prefs [ ’ theme_style ’ ]); $page - > assign ( ’ do ’ , $do ); $page - > pushTpl ( ’ header . tpl ’ ); ... $page - > finish ( ’ footer . tpl ’ );
Šablony mají příponu ’.tpl’ a jsou psány v jazyce HTML. Podporují vložení PHP kódu a to buď stejně jako v HTML použitím značek nebo zkrácenou variantou - uzavřením mezi složené závorky {}. Ukázka kódu šablony s využitím obou variant: < table class = " history " >
< th >{ L ( ’ previousvalue ’ )}
{ L ( ’ newvalue ’ )}
< td >{! $d etails _prev ious }
{! $details_new }
V PHP kódu uvnitř složených závorek lze volat i funkce: < select name = " project_id " > {! tpl_options ( $fs - > projects , Post :: val ( ’ project_id ’ , $proj - > id ))}
21
K tématu šablon patří i zmíňka o funkci L(). Tato funkce, stejně jako například v Drupalu15 funkce t(), zajišťuje zobrazení textu v jazykové mutaci zvolené uživatelem. Argumentem funkce je klíčové slovo, podle kterého je v souboru s překlady vybrán řetězec pro zobrazení. Následující kód: { L ( ’ email ’ )}
tak zajistí vypsání řetězce ’E-mail’, pokud Flyspray používá Čech nebo Angličan, ’Correo’ v případě španělsky mluvícího uživatele a ve Švédsku se objeví nápis ’Epost’ . Soubor s jazyky je jednoduché pole definované v PHP a uložené ve složce lang pod názvem <jazykový_kód_státu>.php: $translation = array ( ’ edituser ’ ’ username ’ ’ realname ’ ’ emailaddress ’ ’ jabberid ’ ... );
=> => => => =>
’ Bewerk ␣ gebruiker ’ , ’ Gebruikersnaam ’ , ’ Echte ␣ naam ’ , ’E - mailadres ’ , ’ Jabber ␣ ID ’ ,
Proměnné TODO: důležité proměnné, výpis uživatelských práv
15
Oblíbený modulární systém pro správu obsahu.
22
4
Analýza nedostatků systému Flyspray
4.1
Využití systému Flyspray v rámci ZČU
TODO
4.2
Hromadná editace úkolů
Ve stabilní verzi systému Flyspray není hromadná editace úkolů implementována. V poslední verzi (dále označována jako současná verze), 1.0.0dev, tato funkce již existuje, ale není provedena optimálně. Z toho důvodu je nutné funkci přebudovat, rozšířit tak její možnosti a ulehčit její používaní. Hromadná editace úkolů je ideální nástroj například pro manažera projektu, protože může s nástrojem pracovat daleko rychleji. V současné verzi není funkce hromadných úprav dostupná přímo na stránce se seznamem úkolů. Po vybrání úkolů je nutný přechod na novou stránku s editačním formulářem. Vynechání tohoto zbytečného mezikroku by rozhodně práci ještě urychlilo. Následující seznamy shrnují posloupnost kroků vedoucích k hromadné editaci ve staré verzi a ideální posloupnost kroků v nové verzi: Původní verze 1. uživatel zaškrtne úkoly, které chce editovat 2. uživatel v rozbalovací nabídce ve spodní části stránky vybere akci „Mass edit” 3. uživatel klikne na tlačítko „Take action” 4. uživatel je přesměrován na stránku s editačním formulářem 5. uživatel provede změny 6. uživatel potvrdí kliknutím na tlačítko „Apply changes” 7. dojde k editaci úkolů (uživatel zůstává na stránce s editačním formulářem)
Upravená verze 1. uživatel zaškrtne úkoly, které chce editovat 2. uživatel ve spodní části stránky provede ve formuláři změny 3. uživatel klikne na tlačítko „Edit multiple fields” 4. dojde k editaci ůkolů (uživatel zůstává na stránce s výpisem úkolů)
23
Editovatelné položky Ve verzi 1.0.0dev je možné definovat vlastní položky (custom fields) a v ideálním případě by bylo vhodné umožnění jejich modifikace v plné šíři. Stávající hromadné úpravy sice nabízejí editaci vlastních položek, ale pouze těch, které jsou nadefinovány globálně pro všechny projekty. V nové verzi by měla být možnost editovat všechny uživatelem definované položky, pokud budou zobrazeny úkoly pouze jednoho projektu. Pokud budou zobrazeny položky všech pojektů (All projects), je nejlogičtějším řešením editace globálně nastavených položek. Přidání závislosti na jiném projektu Někdy se stává, že se objeví chyba či jiná prerekvizita, která blokuje ostatní tickety od uzavření. Bylo by možné tuto skutečnost také hromadně ošetřit. V editačním formuláři by mohlo být vstupní pole určené k zadání identifikačního čísla úkolu, na kterém jsou vybrané úkoly závislé. Tato funkce je zatím dostupná pro jednotlivé položky, nikoliv však v hromadné editaci.
4.3
Integrace se systémem správy revizí
Obecně o verzování „Verzování je způsob uchovávání historie veškerých provedených změn obecně u jakékoliv digitální informace.”[11] V oblasti vývoje softwaru se nejčastěji evidují a spravují změny zdrojových kódů. Systémy pro správu revizí (source|revision|version-control systems) jsou často využívány programátorskými týmy, protože umožňují synchronizovanou spolupráci více lidí na jednom souboru, řeší kolize a spojení různých vývojových větví. Každé změna uložená do úložiště je označována jako revize a má přiděleno unikátní číslo (revision number, id), které se pokaždé inkrementuje o 1. V současnosti jsou tyto nástroje nepostradatelné při seriózním vývoji jakéhokoliv softwaru. O to závažnějším nedostatem systému Flyspray je jeho téměř nulová podpora verzovacích systémů. Jen pro porovnání, konkurenční produkty Bugzilla, JIRA, Redmine či Trac podporují bez vyjímky nejpoužívanější verzovací systémy Subversion (SVN), Mercurial, CVS a Git. Komunikace Flyspray - úložiště Pod pojmem komunikace mám na mysli propojení systému Flyspray pomocí hypertextových odkazů s úložištěm. V praxi by to znamenalo, že v případě výskytu klíčového slova v popisu nebo komentáři bug reportu by se tento řetězec změnil v odkaz směřující na příslušnou revizi v úložišti. Podmínkou je nastavení přístupových informací v administraci projektu. V první fázi integrace Flyspraye s verzovacími systémy uvažujeme volbu systému Subversion, především kvůli jeho velké popularitě.
24
Komunikace úložiště - Flyspray Některé verzovací systémy (např. Subversion, Git) umožňují vytvoření skriptů, které jsou spuštěny na základě provedené akce v úložišti - např. po nahrání nové verze (commit), před nahráním nové verze atd. Těmto skriptům se říká hooks. Jedná se o velice užitečnou věc, lze například provést kontrolu dat ještě před jejich nahráním (pre-commit hook), nebo je možné odeslat e-mail po nahrání dat (post-commit hook). V našem případě je vhodný post-commit hook k tomu, aby po nahrání dat notifikoval Flyspray. Pokud by se nahraná data týkala nějaké chyby uvedené ve Flysprayi a programátor by v komentáři commitu uvedl klíčové slovo identifikující bug report (např. bug#34, FS#3), došlo by k uložení komentáře commitu k příslušnému bug reportu.
4.4
Statistiky a časový management
V kapitole „Význam bugtrackingu” jsem zmiňoval možnosti získání cenných statistik z dobře vedeného bugtrackeru. Analytická část, stejně jako podpora verzovacích systémů, ve Flysprayi zaostává za svými konkurenty a je to velká škoda. V současné době je implementován jediný statistický ukazatel a to je progress bar znázorňující procentuelní pokrok v práci na otevřených bug reportech.
Obrázek 8: Progressbar implementovaný ve FS. Burn down chart Graf znázorňuje zbývající práci na projektu v závislosti na čase (viz obrázek 9). Vertikální osa ukazuje množství práce a horizontální čas. V ideálním případě má graf klesající tendenci a konverguje k nulové hodnotě na vertikální ose (už nezbývá žádná práce) a datumu vydání softwaru na horizontální ose. Burn down graf je často využíván v agilních metodikách softwarového inženýrství. V systému Flyspray by mohla u každého bug reportu být položka odhadovaného času k vyřešení problému a reálného času stráveným prací na problému. Z těchto dat by se generoval burn down chart podobný jako na obrázku.
25
Obrázek 9: Příklad burn down grafu. Zdroj: Wikipedia.
4.5
Integrace s wiki
Dalším užitečným rozšířením by mohlo být propojení projektů v bugtrackeru s wiki stránkami. Každý projekt by měl editovatelné vstupní pole pro definici adresy wiki stránek. V URL wiki stránek by bylo využito zástupného řetězce pro definování konkrétní stránky. Tato nová funkce by měla své opodstatnění jistě i na Katedře informatiky a výpočetní techniky16 , protože je zde využíváno wiki stránek k soustředění informací o projektech.
4.6
Použitelnost UI
TODO: napsat postřehy na vylepšení
16
Katedra informatiky a výpočetní techniky na Západočeské univerzitě.
26
5
Realizační část
Po domluvě s vedoucím mé bakalářské práce, panem Ing. MSc. Přemyslem Bradou, Ph.D., jsem pracoval na nejpotřebnějších úpravách systému Flyspray, a to nejen z hlediska Západočeské univerzity, ale i z všeobecných požadavků na rozšíření funkcionality systému. Při práci na projektu jsem využíval SVN repozitář poskytovaný on-line službou pro správu projektů Assembla.com17 a poznámky jsem zaznamenával do on-line zápisníku Evernote18 .
5.1
Hromadná editace úkolů
Zobrazení editačního formuláře Editační formulář se zobrazuje ve spodní části na stránce „Tasklist”, která je implicitně nastavena jako výchozí stránka projektu. Zobrazení stránky „Tasklist” je provedeno pomocí načtení odpovídající šablony: $page - > pushTpl ( ’ index . tpl ’ );
Následuje zobrazení záložek formuláře (viz obrázek 6), které je podmíněno vlastnictvím přístupových práv k jednotlivým úkonům. Nemá-li např. uživatel právo uzavřít bug report, nezobrazí se mu ani příslušná záložka. if ( $user - > perms ( ’ modify_own_tasks ’) || $user - > perms ( ’ modify_all_tasks ’)) { $page - > pushTpl ( ’ index . tabs . edit . tpl ’); }
Systém Flyspray ve verzi 1.0.0dev obsahuje uživatelsky definované položky, které je také potřeba zahrnout do možnosti editace. Při inicializaci proměnných systému vznikne pro každý projekt instance třídy Project a ta v proměnné $fields uchovává právě množinu uživatelem definovaných polí pro konkrétní projekt. Toho jsem využil a pomocí konstrukce foreach zpřístupnil všechna uživatelská pole. fields as $field ): ? > ... < th id = " f { $field - > id } " >{ $field - > prefs [ ’ field_name ’ ]} ...
Přes veškerou snahu co nejméně zasahovat do originálního kódu, jsem se nevyhnul malé změně šablony index.tpl. Kvůli zahrnutí formulářových položek hromadné editace jsem rozdělil původní formulář do dvou šablon tak, že konec formuláře se nachází až za položkami hromadné editace (v šabloně index.footer.tpl). 17
Changeset je dostupný na adrese: https://www.assembla.com/code/flyspray_dev10-zcu/subversion/changesets/ 18 Zápisník je dostupný na adresách: http://www.evernote.com/pub/jendarybak/flyspray http://www.evernote.com/pub/jendarybak/flyspray-implementace
27
Obrázek 10: Formulář hromadné editace úkolů. Přidání závislosti na jiném projektu Byla nově přidána funkce hromadného nastavení závislosti úkolů. V záložce „Add dependency” je možné skupině vybraných úkolů přiřadit jeden úkol, který je blokuje od uzavření. Výkonná třída FlysprayDoMassedit Po odeslání formuláře hromadné editace je v superglobální19 proměnné $_POST20 uložena proměnná action s hodnotou massedit, což je ve třídě FlysprayDoIndex (scripts/index.php) zachyceno a vyhodnoceno jako pokyn k zavolání třídy zpracovávající hromadné operace FlysprayDoMassedit (scripts/massedit.php). Zároveň jsou odeslána identifikační čísla vybraných úkolů a nové hodnoty z formuláře. Posledně jmenovanou třídu jsem vytvořil dle vzoru ostatních obslužných tříd - všechny mají stejnou strukturu. Funkce action_massedit() vykonává veškeré úpravy, jak je nastíněno v níže uvedeném pseudokódu. Každá funkce, která vykoná nějakou změnu (editace, uzavření,..), vrátí informaci o úspěšnosti akce. Vytvořil jsem proto pole uchovávající identifikátory úspěšně resp. neúspěšně pozměněných úkolů. Uživatel je na závěr přesně informován o výsledku operace. 19 20
Předdefinované proměnné, které jsou vždy viditelné v jakékoliv části skriptu. Pole proměnných přijatých prostřednictvím HTTP POST metody.
28
inicializace proměnných s hr om až ď uj íc íc h informace o výsledcích operací pro všechna task_id { pokud uživatel provedl nějaké změny { pro každou změnu : přidej změnu do pole $args [ $change ] pokud pole assignees není prázdné { pro každého assignee : přidej uživatele ( assignee ) do pole $args [ $assigned_to ] } pokud byly přidány závislosti na jiné položce { pro každou položku : uprav položku - přidej závislost task_id na tuto položku } zavolej funkci pro úpravu položky task_id ( parametr : $args ) ulož výsledek } pokud uživatel uzavřel položku task_id { zavolej funkci pro uzavření položky task_id ulož výsledek } pokud uživatel zvolil hromadnou akci { zavolej funkci pro vykonání hromadné akce ( parametr : pole všech task_id ) } zobraz uživateli výsledek provedených operací }
Ukázka výpisů 1. vše proběhlo v pořádku
2. editace některých položek se povedla, u některých došlo k chybě
3. editace kvůli chybě vůbec neproběhla
29
5.2
Vytvoření odkazu na SVN repozitář
Ve výčtu uživatelských práv najdeme i oprávnění view_svn, které ovlivňuje zobrazení informací z SVN úložiště. Pouze uživatelé s tímto oprávněním mají povoleno zobrazování odkazů na SVN repozitář. Parsování syntaxe Formátování textového výstupu mají na starosti tzv. syntax pluginy umístěné ve složce includes/syntaxplugins/. Momentálně jsou k dispozici následující čtyři: • FlyspraySyntax • MediaSyntax • SmileySyntax • WikiSyntax Implicitně je aktivován plugin FlyspraySyntax, ale nastavení lze samozřejmě změnit při editaci úkolu. Zároveň ve třídě FlyspraySyntax vrací funkce isBasic() hodnotu true, což znamená, že se formátováním tohoto pluginu řídí i „běžný” uživatelský text (např. komentáře). Po ověření práv a existence přístupových informací k úložišti se pomocí regulárního výrazu21 (REGEX) najdou shody s řetězci (klíčovými znaky): rev # revision # revision rev
V okamžiku nalezení výskytu řetězce je hledáno číslo revize bezprostředně za řetězcem a je-li nalezeno, jsou data (výstup reg. výrazu) odeslána jako argumenty funkce tpl_svnlink() v šablonovací třídě Tpl. $input = p r e g _ r e p l a c e _ c a l l b a c k ( " /\ b ( " . implode ( ’| ’ , $look ) . " )(\ d +)\ b / " , ’ tpl_svnlink ’ , $input );
Funkce tpl_svnlink($rev_string) Hlavním úkolem této funkce je získání odkazu na odpovídající revizi v úložišti. Adresu odkazu není složité vytvořit, má následující tvar: < adresa_úložiště >/! svn / bc / < číslo_revize >/ 21
Řetězec popisující regulární jazyk. Technika vhodná k ověřování shody a úpravám textu podle definovaného vzoru.
30
Stačí tedy z nastavení projektu získat adresu úložiště, spojit s částí adresy směřující na starší revize a s konkrétním číslem revize, které jsme získali pomocí regulárního výrazu. V popisku odkazu se po najetí myši zobrazuje komentář vytvořený uživatelem při commitu (odeslání dat do úložiště) včetně datumu commitu. Komentáře získáme z logu umístěném na SVN serveru. Součástí instalace systému Flyspray je třída SVNInfo obsluhující komunikaci se serverem. Ukázka stažení logu: $svninfo = new SVNinfo (); $svninfo - > setRepository ( $proj - > prefs [ ’ svn_url ’] , $proj - > prefs [ ’ svn_user ’] , $proj - > prefs [ ’ svn_password ’ ]); $logsvn = $svninfo - > getLog ( $rev_number , $rev_number );
Z hlediska výkonnosti není výhodné se pokaždé, když se v textu objeví odkaz na úložiště, připojovat k SVN serveru a stahovat logy. Problém jsem vyřešil ukládáním informací do cache při prvním načtení logu daného commitu. Data v cachi expirují po 30 dnech a z administrace projektu je možné cache kdykoliv vyprázdnit.
5.3
Vytvoření odkazu na SVN changeset
V původní verzi nebylo, narozdíl od konfigurace adresy úložiště, možné nastavit a odkazovat na adresu changesetu. Přidal jsem tuto možnost do administrace projektů. Nejprve jsem upravil šablonu formuláře (pm.prefs.tpl) na stránce „project management” tak, aby bylo možné zadávat do formuláře URL changesetu (viz obrázek TODO). Adresa musí být uložena v databázi - v tabulce <prefix>projects proto přibyl sloupec chs_url (datový typ varchar(255)). Uložení dat z formuláře do databáze zajišťuje skript pm.php. Adresa changesetu se může u různých poskytovatelů lišit a je nutné odlišit číslo revize od dalších možných čísel v URL. Řešení, které jsem implementoval, využívá zástupného znaku (placeholderu) v adrese. Ukázka adresy changesetu včetně placeholderu ($): http :// www . assembla . com / code / flyspray_dev10 - zcu / subversion / changesets / $
D
Placeholder je uživatelsky nastavitelný v administraci systému (Admin Toolbox Preferences General) a je globálně platný pro všechny projekty. Úpravy v kódu jsou podobné jako u nastavení adresy changesetu s tím rozdílem, že data jsou uložena v tabulce <prefix>prefs.
D
Funkce tpl_svnlink($rev_string) Stejně jako v předchozí kapitole tato funkce vytváří odkaz. V případě, že je adresa changesetu uživatelem zadána, nevytváří se odkaz na SVN repozitář, ale na SVN changeset. Je to tak nastaveno z důvodu lepší názornosti changesetu. V kódu je vytvoření odkazu vyřešeno nahrazením placeholderu v adrese changesetu číslem revize: $link = str_ireplace ( $placeholder , $rev_number , $proj - > prefs [ ’ chs_url ’ ]);
Z analýzy nedostatků vyplynul požadavek na možnost přidávání komentářů prostřednictvím API. Ačkoliv je v nové verzi systému Flyspray integrovaná podpora několika API funkcí, mohou nastat problémy s jejich použitím. URL volání API funkce obecně mají následující tvar: < Flyspray_root >/ index . php ? do = api & action = < pažadovaná_akce >& id = < identifikátor_úkolu >& < další parametry >
Jak je vidět, identifikátor úkolu je pevně zakotven v URL a není-li na tomto místě uveden, vykonání funkce se neuskuteční. To může být problém pokud chceme Flyspray propojit pomocí API s některými systémy třetích stran, jako jsou například on-line systémy pro správu projektů (Assembla.com, Unfuddle.com, apod.). U takových systémů nemáme možnost upravit volání API podle našich představ, ale musíme se spokojit s poskytovanými prostředky. Často tyto nástroje nabízejí možnost zavolání uživatelem zvolené adresy po vykonání určité akce, nejčastěji commitu v úložišti, vytvoření ticketu apod. Funkce
32
bývá označována jako webhook. Zmíněný problém tkví v tom, že do adresy webhooku nedokážeme dostat identifikátor úkolu, tím pádem není možnost pomocí API provést akce spojené s konkrétním úkolem. Problém jsem vyřešil úpravou skriptu api.php. V případě, že mu není předána proměnná id, skript se neukončí, ale zaměří se na tělo zprávy. V těle hledá výskyt klíčových slov odpovídajících vzoru uvedeném níže: FS # < číslo > bug # < číslo > FS < číslo > bug < číslo >
Dojde-li ke shodě se vzorem, je získáno <číslo> a to je považováno za identifikátor úkolu ve Flysprayi. K tomuto úkolu se pak vztahuje akce volaná prostřednictvím API. Testování shody se vzorem je zobrazeno v ukázce kódu: $look = array ( ’ FS # ’ , ’ bug # ’ , ’ FS ’, ’ bug ’); $pattern = ".*(" . implode ( ’| ’ , $look ) . ")([0 -9]*).*"; eregi ( $pattern , Req :: val ( ’ comment ’). Req :: val ( ’ text ’) , $regs );
5.5
Instalační balíček
K úspěšné a pohodlné aplikaci vytvořených změn jsem vytvořil balíček obsahující modifikované soubory a upgrade-skript vytvořený podle standardu používaném ve Flysprayi při přechodu na vyšší verzi. Balíček slouží k upgradu z verze 1.0.0dev. Využití skriptu je výhodné, protože uživatel nemusí ručně provádět změny v databázi. Struktura Umístění upgradovacích souborů je setup/upgrade/1.0.0.1/. Zde se nacházejí následující soubory: • upgrade.info – [defaultupgrade] obsahuje seznam upgradovacích souborů v pořadí, v jakém se mají spouštět – [fsprefs] obsahuje tabulku nastavení, která bude převedena do DB jako tabulka <prefix>prefs • upgrade_projects.xml – ve formátu XML obsahuje strukturu modifikovaných databázových tabulek • flyspray.conf.php – konfigurační soubor obsahuje základní nastavení systému Flyspray 33
Instalace Instalace změn spočívá v překopírování souborů balíčku do kořenového adresáře instalace systému Flyspray verze 1.0.0dev a spuštění skriptu na adrese /setup/upgrade.php. Pak už stačí jen kliknout na tlačítko „Upgrade” a instalace proběhne.
5.6
Testování
Testovací prostředí TODO: prostředí PHP verze / apache apod. Postup testování TODO: QA body Testovací data TODO
5.7
Možná vylepšení
TODO
34
5.8
Zveřejnění
Věřím, že modifikace, které jsem v rámci mé bakalářské práce vypracoval, jsou užitečné nejen pro účely univerzity, ale i pro ostatní uživatele systému Flyspray. Proto jsem připravil veřejně přístupný web, na kterém jsou vysvětleny všechny úpravy, jsou zde zdrojové kódy ke stažení a ukázková instalace. Web je dostupný na adrese: http://students.kiv.zcu.cz/~rybak/.
Obrázek 13: Web prezentující modifikace vytvořené v rámci této BP.
35
6
Závěr
36
Přehled zkratek API
Application Programming Interface
BT
Bug tracking
BTS
Bug tracking system
CSS
Cascading Style Sheets
CVS
Concurrent Version System
DB
Databáze
HTML
HyperText Markup Language
PEAR
PHP Extension and Application Repository
PHP
PHP: Hypertext Preprocessor
PHP5
PHP: Hypertext Preprocessor version 5
QA
Quality Assurance
REGEX
Regular Expression
RUP
Rational Unified Process
SCM
Software Configuration Management
SQA
Software Quality Assurance
SVN
Subversion
SŘBD
Systém řízení báze dat
USD
United States Dollar
UTF-8
8-bit UCS/Unicode Transformation Format
XHTML
HyperText Markup Language
XML
Extensible Markup Language
XMPP
Extensible Messaging and Presence Protocol
XP
Extreme Programming
37
Reference [1] Humphrey, W.S ., Managing the Software Process, New York: Addison-Wesley, 1989 [2] Datamonitor Group. Software: Global Industry Guide 2009. URL: [cit. 2010-05-01] [3] The Standish Group International, Inc. URL: [cit. 2010-05-01] [4] The Standish Group International, Inc. Chaos Summary for 2009. URL: [cit. 2010-05-01] [5] Leveson, Nancy, Safeware: System Safety and Computers, New York: AddisonWesley, 1995 URL: [cit. 2010-05-01] [6] Prof. J. L. Lions, Ariane 501 Inquiry Board report, Paris, 1996 URL: [cit. 2010-05-01] [7] National Institute of Standards and Technology URL: [cit. 2010-05-02] [8] RTI for Tassey, Gregory, Ph.D., National Institute of Standards and Technology, 2002 URL: [cit. 2010-05-02] [9] Bug tracking system. URL: [cit. 2010-05-02] [10] Kolawa, Adam, Making Your Bug Tracking System Work for You. URL: [cit. 2010-05-02] [11] Verzování. URL: [cit. 2010-05-04]
