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

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í.

Zdroj: https://www.zdrojak.cz/?p=3605