Verzovací systém + bugzilla

17.7.2011 16:52 | Přečteno: 1808× | IT obecně

Jedny z nejdůležitějších nástrojů používaných v každém vývojářském týmu jsou verzovací systém (Mercurial, SVN, Git, CVS atd.) a systém na správu chyb/požadavků (Bugzilla, Trac atd.). A většinou se řeší nějaká jejich integrace – když uděláme změny v kódu, chceme u nich mít poznamenané, jakou chybu řeší. A naopak u chyb/požadavků bychom rádi v jejich historii viděli, jak práce postupuje a jaké změny kódu byly v rámci daného úkolu provedeny. Co takhle oba systémy spojit do jednoho? Něco takového dělá Fossil. Ale možná by to šlo vyřešit obecně pro libovolný verzovací systém.

Představa je taková, že v úložišti by byla nějaká složka – např. úkoly – a v ní by byly očíslované podsložky s jednotlivými úkoly a uvnitř nich soubory s popisem, stavem, komentáři a dalšími metadaty. Nad tím by byla nějaká nadstavba (klientský software), která by umožňovala úkoly (chyby/požadavky) zobrazovat, vyhledávat v nich, přidávat komentáře, měnit stavy atd.

Výhody:

• Úkoly a kód by byly pěkně pohromadě.
• Jednoduchá práce s větvemi/verzemi – chyba/požadavek bude vytvořená v nějaké větvi, půjde propagovat společně s řešením (zdrojákem) do jiné atd.
• Úkoly by šlo přidávat nebo upravovat i offline (třeba v letadle, ve vlaku, s pomalým mobilním připojením atd.), stejně jako to můžeme dělat s kódem.
• Jeden protokol pro přístup k oběma systémům, jedny uživatelské účty, jeden server. Není potřeba provozovat webový a databázový server kvůli systému na správu chyb – stačí verzovací systém, který může být teoreticky i na sdíleném disku.

Nevýhody:

• Historie změn kódu bude zaneřáděná změnami v úkolech. Tohle by chtělo nějak účinně filtrovat. Navíc to bude zkreslovat různé metriky.
• Hodně práce s vývojem takového systému.
• Absence serverové části může být i nevýhoda pro pokročilejší funkce.
• Problém při práci na více programech/projektech – systém na správu úkolů bude roztříštěný do několika úložišť, zatímco software typu Bugzilla můžeme mít jeden společný pro všechny projekty.

       

Anketa

Anketa

Komentáře

[vlanav]

Trac?

[xkucf03]

Však ten používám Ale někdy přemýšlím, jestli by to nešlo i jinak – třeba pro různé malé projekty, kde se s tím člověk nechce rozcházet, nebo pro nějaké soukromé účely – jednoduchá evidence úkolů, když ani nemám ty zdrojáky na serveru a verzuji si to jen lokálně.

[msk]

Git + OO Calc

[msk]

Trac?

Mne takisto pride, ze sa objavuje koleso. Co uloha, to ticket v trac-u. V komentari sa da nalinkovat revizia, alebo branch, ktory to riesi. Problem skor vidim na opacnej strane barikady - mnohokrat mam niekolko malych dielcich uloh ( ticketov ), ktore spolocne ( nevedomky ) opravim v ramci jedneho jedineho commitu/branchu. A potom 3 tickety odkazuju na jeden bundle zmien, kde nie je exaktne jasne na prvy pohlad, ktora uprava riesi ktory ticket.

Dalsou otazkou ale je, nakolko je potrebne toto nejak extrahovat a pripravovat na striebornom podnose. Nepamatam sa, ze by som niekedy nutne po sebe cital diffy. Urcite nie pravidelne. A pokial som to potreboval, tak som si precital komentar a spravil adekvatny diff.

[retroslava]

Co Github?

[RapMan]

Pouzivame v praci gforge, zatim spokojenost.

[pavlix]

Hodně se toho dá vyřešit v gitu... repozitář může obsahovat větve, které nemají společnou historii, nebo může obsahovat submoduly. Nebo se to dá různě kombinovat. Mně osobně se nejvíc líbí to, že neexistují žádná předem daná omezení, jak data uložená v gitu použít. Takže nad tím jde postavit relativně cokoli.

[Karel Zak]

Neni lepsi nez vytvaret monstrum tak nejak smysluplne adresovat mezi existujicima SCM a bug-tracks?

Bezne lide do git commit message pridavaji nejake "Addreses: url-bugu". Nemel by byt zase tak velky problem na strane gitu udelat nejaky hook co by zapisoval do (napr.) bugzilly a pridavat tam nejaky odkaz na commit. Jednoduse tam muzete podporovat ruzne bug-track systemy na ruznych mistech. Protoze jak znamo tak rada OSS projektu resi reporty z ruznych mist (distribuci apod.)

[dementni.lojzik]

Nemel by byt zase tak velky problem na strane gitu udelat nejaky hook co by zapisoval do (napr.) bugzilly a pridavat tam nejaky odkaz na commit.

ano, co jsem videl, tak se to tak bezne dela (priklad, sice to neni s bugzillou ale jirou, ale zas je tam jeste navic ukazka IMHO velmi dobreho postupu, a to nasledneho propojeni s kontinualni integraci, ci jak se to spravne cesky nazyva)

[alblaho]

A ten Fossil nefunguje? Já na to před pár měsíci koukal a vypadalo to zajímavě, ale nezkoušel jsem to.

Ale asi bych se těžko vzdával Gitu. Líbil by se mi nějaký hodně hodně lehký issue tracker integrovaný do gitu.

[pavlix]

Líbil by se mi nějaký hodně hodně lehký issue tracker integrovaný do gitu. Váš komentář

Určitě nějaký bude. Jen je otázka, jestli bude v nějaké lepší fázi než proof of concept.

[xkucf03]

Už existuje: mercurial-bugtracker-extension