nav line

Verzovací systém a webintegrační projekty

Proč využití verzovacího systému zvyšuje kvalitu vývoje web integračního projektu? Jaké jsou výhody použití verzovacího systému a jeho celkový vliv na vývoj?

Verzovací systém (Version Control System, VCS) hraje významnou roli ve vývoji webintegračního projektu. Primárním účelem využití VCS je zaznamenání změn při vývoji projektu a jejich propagace napříč týmem a mezi různými prostředími. Moderní verzovací systémy řeší nejen problém spolupráce a zaznamenávání změn, ale přináší i řadu dalších výhod.

O VCS se opírají nástroje pro tzv. průběžnou integraci (Continuous integration). Takovými nástroji jsou například Jenkins, Hudson, Bamboo a s jejich pomocí můžeme automatizovat testování aplikací a jejich deployment. Na testy a deployment nakonec ještě navážeme reporting v podobě e-mailových nebo jiných notifikací.

Charakteristika nejoblíbenějších verzovacích systémů

Subversion (SVN) je tradiční zástupce klient-server aplikace. Po dlouhou dobu byl dominantním systémem pro správu revizí. SVN šetří prostorem, využívá rozdílové revize. Projekt je verzován v centrálním úložišti na serveru a pro verzování je nutné funkční spojení se službou na serveru.

Git a Mercurial představují distribuované systémy s podobnou filozofií. Hlavním rozdílem těchto dvou systémů oproti SVN je fakt, že každý vývojář může pracovat lokálně a nepotřebuje pro práci spojení se serverem. Kromě toho může vývojář odevzdat na vzdálený server pouze část své práce a jinou část si ponechat lokálně pro pozdější úpravy.

Git je velmi flexibilní. Jde o celou sadu jednoúčelových nástrojů a je možné ho snadno rozšiřovat o nadstavby. Využíváme například gitflow. Naproti tomu Mercurial je jedna kompaktní knihovna a ukazuje se jako málo flexibilní. Pro podrobnější srovnání gitu a Mercurialu doporučuji článek Git vs. Mercurial.

Decentralizovaná povaha vývoje s centrálním repositářem

Vývoj projektu se odvíjí ve více či méně decentralizovaném schématu. Každý vývojář pracuje na své lokální kopii projektu. Vývojáři pracují v určitých týmech a to i geograficky oddělených. Různé týmy využívají pro vývoj a testování svoje lokální prostředí předtím než určitý balík změn nasdílí dalším týmům. Se vzrůstajícím množstvím týmů a vývojářů roste i riziko, že dva vývojáři zasáhnou do stejné části aplikace a provedené změny budou ve vzájemném konfliktu. Distribuované VCS se na řešení takových problémů hodí lépe.

Existuje celá řada přístupů centralizované i decentralizované povahy, které řeší různé modely spolupráce (viz např. Workflow).

Jednotný systém a standardizace vývoje

Nastavení jednotné formy verzování změn a systému odevzdávání práce udává pravidla pro práci vývojářů a přináší tak pevný základ pro standardizaci vývoje a distribuci. Pro vývojáře to znamená jednoznačně určené procesy a tím i návod pro řešení možných situací, které mohou nastat.

Aktualizace aplikací v různých prostředích je při absenci VCS problematická. V praxi využíváme kontinuální integraci pomocí nástroje s vazbou na VCS.

Dále zjednodušuje spuštění projektu a jeho aktualizaci během provozu v testovacím i produkčním prostředí, snižuje náklady spojené s předáváním práce a kontrolou.

Vlastní vs. pronajatá služba

Verzovací systém lze provozovat na vlastním serveru. Toto řešení skýtá maximální možnou konfigurovatelnost. U projektů, které pracují s citlivými daty klientů, je dokonce nutností, aby zdrojové kódy nebyly veřejně dostupné a bylo zajištěno, že se k nim za žádných okolností nedostane nikdo jiný než odpovídající vývojáři.

Pokud se sami nechceme věnovat provozu verzovacího systému, využíváme specializované hostingové služby s podporou požadovaného verzovacího systému. Github podporuje paralelní využití gitu i SVN, což dává vývojářům volnost ve výběru verzovacího systému.

Migrace mezi službami

Všechno se vyvíjí. V minulosti jsme v Lundegaardu provozovali vlastní SVN server a git server. I přes své výhody bylo potřeba se posunout dál a ke slovu přišlo využití hostovaných služeb.

První migraci představuje přechod z vlastního serveru na GitHub. Později jsme přesunuli své projekty z GitHubu na Bitbucket.

Přesun repositářů na GitHub

Migrace na GitHub představuje pouze několik jednoduchých kroků.

  1. Vytvoření repositáře na GitHubu.
  2. V původním umístění na našem serveru nastavíme jako vzdálený repositář ten, který jsme vytvořili v bodu 1.
  3. Odešleme celou historii do vzdáleného repositáře.
  4. Nastavíme security pro vývojový tým a informujeme jeho členy o provedené migraci.

Toť vše – práce na projektu může nerušeně pokračovat.

Přechod z GitHubu na Bitbucket

Migrace projektu nejen mezi GitHubem a Bitbucketem je možná pomocí importu. Jde o pohodlný způsob, kdy pomocí jednoho formuláře vytvoříme repositář na Bitbucketu a zároveň zadáme údaje potřebné pro přístup k původnímu repositáři na GitHubu.

Jak můžete vidět, taková migrace je ještě jednodušší než přesun na GitHub.

Prolínání verzovaných a neverzovaných částí aplikace

Prakticky v každém webintegračním projektu se nachází části, které verzovat nechceme. Vývojáři potřebují lokální nastavení pro různá prostředí (například nastavení připojení k databázi). V uživatelské úrovni máme data spravovaná uživateli prostřednictvím Content Management Systému (texty, obrázky, videa,…). Tyto části potřebujeme mít mimo verzovací systém. Je to nežádoucí jednak z bezpečnostních i čistě praktických důvodů. Uživatelská data také představují velké množství dat. Verzování je minimálně problematické a většinou úplně nemožné.

Na projektech řešíme situaci zařazením konfiguračních souborů a datových složek do seznamu ignorovaných částí projektu. V gitu je takové nastavení obsahem souboru .gitignore, kde lze vyjmenovat konkrétní soubory i celé složky a nastavovat pravidla pro ignorování souborů parametricky (podrobnosti např. v GitHub help).

Pozitivní dopady verzovacího systému na vývoj webintegračního projektu

Verzovací systém se v životním cyklu webintegračního projektu dotýká hned několika oblastí:

  • spolupráce vývojářů, kteří bývají na geograficky rozdílných místech a mohou být i rozdílného profesního zaměření,
  • zodpovědnost spojená s dohledatelností zásahů do aplikačního kódu,
  • bezpečné nasazování aktualizací – možnost pohybovat se v historii změn umožňuje návrat k předchozí stabilní verzi, pokud se aktualizace ukáže jako nevhodná pro běhové prostředí,
  • dokumentace – záznamy z verzovacího systému doplňují tradiční vývojářskou dokumentaci a přidávají i časový rozměr, díky kterému je možné zpětně sledovat rychlost a mohutnost vývoje. Export dat je možné převést do grafické podoby, kterou ocení zvláště netechnické profese v týmu,
  • audit – po dokončení projektu navážeme na verzovací systém audit projektu,
  • change log – souhrn změn pro určité období lze připravit na základě historie revizí.

Shrnutí výhod a nevýhod

Verzování přináší určité nevýhody. Práce s verzovacím systémem zvyšuje bezprostřední pracnost a vývojáři musí rozšiřovat svoje vzdělání na nové nástroje, které potřebují ke své práci. Verzování ale představuje minimální námahu ve srovnání s vývojem webové aplikace. V praxi se ukazuje, že celková pracnost při vývoji projektu nestoupá. Ušetří se totiž náklady na deployment a samotný vývoj je efektivnější.

Vyšší kvalitou a efektivita vývoje v důsledku vyváží nevýhody. Kromě technických aspektů nastíněných výše je možné zmínit možnost auditu, kterou ocení i manažerské role.

Z uvedeného jednoznačně vychází, že používání verzovacího systému by mělo být součástí vývoje každého webintegračního projektu.

Ohodnoťte článek

Verzovací systém a webintegrační projekty

Diskuse

Pro doplnění k oblíbeným verzovacím systémům: existuje například i verzovací systém Bazzar, méně známý projekt oproti předchozím dvěma matadorům. Ovšem podporu má rozhodně slušnou, za Bazzarem stojí Canonical (společnost zastřešující vývoj operačního systému Ubuntu a dalšího open source softwaru).

Měl jsem za to, že Bazzar umřel?

Související články

Vyhledávání na blogu

Webová integrace

Webová integrace jako nová oblast pro business „velkých" webových agentur.

o webové integraci

Profily blogujících