Přejít k navigační liště

Zdroják » Různé » Integrované systémy pro správu kódu

Integrované systémy pro správu kódu

Články Různé

Pro správu změn ve zdrojovém kódu se používají verzovací systémy. V reálné praxi bývá nutné je integrovat s dalšími nástroji pro ostatní části životního cyklu aplikací – nejčastěji se správou požadavků, bugů a úkolů, velmi často s automatickými nástroji pro vytváření buildů, někdy i se správou testovacích případů a testů.

Historicky se pro správu změn ve zdrojovém kódu používají specializované verzovací systémy, ze starších uveďme CVS, SourceSafe, ClearCase, nověji např. Subversion, Git, Mercurial. Liší se architekturou úložiště (od souborového systému po čistou relační databázi), cenou (od nuly po velmi vysokou), podporovanými operačními systémy apod. Jednu věc ale mají společnou – jedná se o systémy specializované na správu zdrojového kódu a nic dalšího je nezajímá. V reálné praxi bývá nutné je integrovat s dalšími nástroji pro ostatní části životního cyklu aplikací – nejčastěji se správou požadavků, bugů a úkolů, velmi často s automatickými nástroji pro vytváření buildů, méně často se správou testovacích případů a testů. Tato integrace může znamenat relativně jednoduchou konfigurační práci anebo masivní vlastní vývoj. V každém případě se jedná o náklady navíc. Do systému se tím vnáší křehkost – výrazně se komplikuje možnost přechodů na nové verze, která vždy představuje značné riziko pro funkci systému. Navíc ani při nejlepší vůli nelze z takto spojených produktů vytěžit víc než „základní životní funkce“.

V posledních cca 5 letech proto získávají na popularitě integrované systémy pro správu životního cyklu vývoje, jehož je správa verzí zdrojového kódu základním stavebním kamenem. Nejpoužívanějšími produkty v této kategorii jsou Team Foundation Server od Microsoftu, Rational Team Concert od IBM a StarTeam od Borlandu. Díky tomu, že jsou všechny funkční bloky vyvíjené dohromady, jsou spolu dokonale integrovány a poskytují vývojářům i dalším uživatelům nepřekonatelný komfort a opravdovou synergii při používání všech bloků dohromady. Je však nutno zmínit i nevýhody. První z nich je cena. Vzhledem k měsíčnímu platu vývojáře a jeho ušetření práci nebývá nijak astronomická, ale přece jenom je to několikanásobně víc než nula (Cimrmanův matematický vtip). Většina produktů nabízí nějakou startovací edici, kdy lze nástroje pro prvních několik uživatelů získat téměř zdarma. Druhou nevýhodou je menší možnost volby, která je přímo zaplacenou cenou za dokonalou integraci. Jednotlivé komponenty totiž nelze snadno nahradit jinými – nelze tedy např. snadno spojit integrovaný produkt X se systémem pro správu chyb Y. Více či méně jste tedy postaveni před volbu „všechno nebo nic“.

Protože mnozí čtenáři nemají s integrovanými systémy zkušenosti a tedy ani představu, co dobrá integrace obnáší, pojďme si základní principy ukázat konkrétněji. Jako příklad použijeme Team Foundation Server, který nabízí verzovací klienty ve třech formách:

  • .NET klient pro Visual Studio a operační systémy Windows (C#, Visual Basic, C++ apod.)
  • Java klient pro libovolné operační systémy z příkazové řádky, integrace do Eclipse prostředí (Java, PHP, Ruby apod.), který je použit i v ukázkách níže
  • Webový klient v libovolném prohlížeči

Základní výhody integrace si osvětlíme na triviálním praktickém příkladu.

Integrace s pracovními položkami

V každém projektu je třeba nějakým způsobem evidovat práci, ať už jí říkáme jakkoliv – požadavky, chyby, úkoly, změny apod. Je vždy žádoucí vědět, proč byla která úprava v kódu provedena. V neintegrovaných systémech se zpravidla do komentářů ke změnám v kódu vepisují čísla pracovních položek, což je přístup notoricky nespolehlivý. Integrované systémy nabízejí vyšší komfort a naprostou spolehlivost. Pojďme se podívat na typickou situaci. Vývojář přímo ve svém prostředí (v tomto případě Eclipse) vidí seznam a všechny detaily chyby.

Poté může chybu opravit v kódu tak, jak je zvyklý:

V okamžiku, kdy je vše hotovo, chce veškeré lokálně provedené změny uložit, přidá komentář a pokusí se změny uložit:

Teď to začne být zajímavé. Na projektu je nastavena kontrola, která nedovolí uložit změny v kódu, aniž by byly asociovány s nějakou pracovní položkou:

Řešení je velmi jednoduché, stačí vybrat ze seznamu pracovních položek příslušnou chybu (úkol, požadavek) a uložit změny do úložiště zdrojového kódu:

Aby se vývojáři ušetřila práce, pracovní položka je automaticky převedena do dalšího stavu (Resolved, vyřešeno), jak je vidět v historii položky. Nemusí tedy již nikde reportovat, že je práce hotova:

Zároveň vznikne trvalá vazba mezi pracovní položkou (zde bugem) a změnou v kódu. Je tedy možné otevřít pracovní položku a podívat se na asociované změny v kódu:

Ihned je tedy vidět, jaké soubory byly v rámci opravy chyby změněny:

A je možné se snadno podívat, jaké byly konkrétní změny v kódu nutné pro opravu chyby (anebo třeba vyvinutí nové funkčnosti):

Vazba je samozřejmě i opačným směrem. Každý si může zobrazit historii konkrétního souboru, což je samozřejmě běžná věc:

Stejně tak je samozřejmě možné porovnat dvě verze souboru proti sobě anebo využít možnosti anotací, tedy zjistit, v jaké změně byl naposledy konkrétní řádek změněn (zde číslo 367):

Odtud je díky vazbě na pracovní položku pouze jeden klik daleko k zjištění, proč se změna udála – tedy plnému popisu pracovní položky (zde bugu):

Integrace s buildovacími systémy

Používání buildovacích systémů se (bohudík) zvolna stává většinovou praktikou. Slouží jednak k automatické kontrole kvality kódu pomocí kompilace, unit testů či analýzy kódu, ať už prováděné okamžitě po provedení změny (kontinuální integrace) anebo s nějakým časovým odstupem (denní buildy). Druhou využívanou funkcí je vytváření finálního produktu, např. instalačního balíčku aplikace, případně rovnou i instalace aplikace do testovacího prostředí. Integrace v tomto případě nabízí mnohem snazší způsob nastavení buildu, které je integrováno do uživatelského rozhraní a dále zpětnou vazbu z buildovacího systému, díky které lze lehce zjistit, jaké změny obsahuje nově sestavená verze ve srovnání s libovolnou předchozí verzí.

První výhodou je přímá integrace buildovacích služeb, takže například spuštění buildu lze provést přímo z vývojového prostředí (zde Eclipse):

Přímo z vývojového prostředí lze samozřejmě sledovat též průběh a výsledek buildu:

Díky integraci se správou zdrojového kódu je pak možné sledovat změny kódu mezi dvěma buildy, stejně jako vyřešené pracovní položky – a to samozřejmě pouze díky integraci všech systémů, jak je vidět na následujícím obrázku:

Na konkrétním souboru změn anebo pracovní položce je samozřejmě možné kliknout a zobrazit si její detaily, čímž se snadno získají konkrétní informace o kontextu daného buildu. Integrace též umožňuje velmi komfortní funkci kontinuální integrace, tedy automatické kontroly zdraví zdrojového kódu pomocí kontrolní kompilace, testů jednotek apod. po každé změně zdrojového kódu. Díky integraci do vývojového prostředí lze zajít ještě dále. Tzv. gated check-in umožňuje kontrolu kódu ještě před uložením do repository. V případě TFS to může vypadat tak, že vývojář je upozorněn, že kód před uložením do úložiště musí projít kontrolním buildem:

V prostředí je pak vidět probíhající kontrolní build:

V případě problému se změnami jsou tyto vývojáři „hozeny na hlavu“:

V opačném případě je informován o uložení změn na server:

Závěrem

Integrované systémy pro správu životního cyklu vývoje zahrnující verzovací systémy získávají oproti jednoúčelovým systémům na popularitě. Jejich hlavní výhodou je výrazně lepší funkčnost a nesrovnatelný komfort. Nevýhodou je menší flexibilita, neboť jednotlivé bloky nelze snadno nahrazovat jinými. Určitě ovšem stojí za vyzkoušení.

Komentáře

Subscribe
Upozornit na
guest
8 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
jos

„V reálné praxi bývá nutné je integrovat s dalšími nástroji pro ostatní části životního cyklu aplikací – nejčastěji se správou požadavků, bugů a úkolů, velmi často s automatickými nástroji pro vytváření buildů, někdy i se správou testovacích případů a testů.“

autor je zřejmě notorický klikač, což mu neberu (taky sem si tim prošel a po přechodu do textovýho režimu se mi dost ulevilo) a nijak neshazuju kvality představovanýho řešení

v reálné praxi si obvykle vystačíte se samotným verzovacím systémem, který má všechno už integrované, případně existují extenze třtích stran

naše reálná praxe: používáme mercurial, kdyby bylo libo, tak můžeme opustit trac a přejít na http://mercurial.selenic.com/wiki/ArtemisExtension (ve skutečnosti by bylo zapotřebí artemis spřáhnout s tracem, nebo jiným frontendem, protože od testujících uživatelů neočekávam že by zadávali bugreporty v commandlajně)

buildy žádný nevytváříme (protože PHP), ale nechat automaticky pustit příkaz pro komplilaci je pořád jenom automatický puštění příkazu nahookovaný na změnu historie centrálního repository, v naší praxi na to teda máme napsanej offline bazmek (několikařádkovej .sh + cron)

“ … (integrovat) se správou testovacích případů a testů“ – tohle teda moc nechápu, pro nás to sou zdrojáky jako všechny jiný, takže je verzujeme

tdvorak

My to děláme tak, že veškerý zdrojáky verzujeme v GITu. Nad GITem poslouchá CI server Teamcity, kterej po každým commitu do repozitáře provádí sadu různejch testů, od buildovatelnosti, checkstyle a PMD, přes validaci XML, JS a CSS po hledání zapomenutých devel url a emailů. Při commitu do stable větve se navíc celá webová aplikace poskládá, spustí a rozeběhnou se selenium testy následovaný snímkovačem ve 3 různejch prohlížečích. Nakonec běží ještě jednou sada stresstestů, který hlídaj, že se url nezačala načítat nějak podezřele dlouho. Bugy evidujeme ve flysprayi, ale neprovazujeme to nijak na verzovací systém, stojí to nezávisle. Takže nepotřebujeme žádný kompletní řešení, stačí nám zdarma GIT a Teamcity(zdarma pro malé teamy) + úlohy, co jsme si do něj sami dopsali.

vks

no to mi vysvetlete, proc nekdo neco takhle resi kdyz vetsina dulezitych stranek je desne zabugovana, plna testovacich dat a jede odporne pomalu.

tdvorak

No, my se toho snažíme vyvarovat a proto taková mašinérie. Jistě to nezabrání všem problémům, ale je to jako rozdíl mezi testovat/netestovat kód.

vks

jo, cekal bych ze na tomhle serveru budou vsichni opovrhovat TFSkem…
Ma spoustu hezkych featur ale ty jsou jeste trochu nedotazene a na zakladni veci je TFS obcas trochu drevene…
Osobne si myslim, ze git je nejlepsi co dneska mame k dispozici.

jos

buď sem tě nepochopil, nebo nevim kdo tu (aktuálně) opovrhuje TFSkem

Petr

Delsi dobu pouzivame pro mensi tym SVN + CruiseControl.NET + MSBuild scripty. V cem by byla napriklad kombinace GIT + TeamCity(?) prinosem, pri pouziti MSDN Professional urovne ? Na TFS radsi zavislost budovat nechci, byt uznavam ze pro „drazsi“ vyvoj je to asi pohodlna cesta.

Podobny problem jsem resil u MSTest versus NUnit. MSTest je sice pekne integrovany do Visual Studia a v zasade funguje (byt nenabizi nektere komfortnejsi vlastnosti NUnit, ale ty nastesti nechybi). Problem je, ze pro spusteni MSTest testu davkove na serveru je potreba tam nainstalovat cele VS :-/ V tomhle je NUnit jednoznacne vyhodnejsi.

Filip Procházka

A nebo použijete Github, který vám nezabírá prostor v IDE ;)

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.