Průběžná integrace

ikona
Tento článek potřebuje úpravy.
Můžete Wikipedii pomoci tím, že ho vylepšíte. Jak by měly články vypadat, popisují stránky Vzhled a styl, Encyklopedický styl a Odkazy.

Konkrétní problémy: nepřeložené anglické výrazy, velké množství červených odkazů
Proces průběžné integrace a role integračního serveru

Průběžná integrace (angl. Continuous Integration) je souhrnem různých vývojářských nástrojů a metod k urychlení vývoje softwaru a spolupráce týmů. Jedná se o součást metodik extrémního programování. Slouží mimo jiné k urychlení nalezení nedostatků a chyb u softwarových projektů ve fázi vývoje. Pro spojení těchto metod a nástrojů se používají integrační servery. Pod slovem integrace je v tomto článku myšlena systémová integrace. Základem každého softwarového projektu je vydávání tzv buildů. Build je vykompilovaná verze vyvíjeného softwaru. Každý build musí mít svoji identifikaci ve formě verze.

Oficiální definice průběžné integrace pochází od Martina Fowlera, který ji definuje jako metodu vývoje software, kde každý vývojář integruje svoji část práce průběžně (pravidelně) – nejlépe denně[1]. Každá integrace je ověřena automatickými testy k co nejrychlejšímu nalezení chyb (viz článek testování softwaru).

Historie

Průběžná integrace jako metoda se objevila v šedesátých letech ve společnosti IBM, kde prováděli složité build procesy i šestkrát denně. Dalším velkým pokrokem bylo napsání článku [2] Martinem Fowlerem. Následně se začala tato metodologie hromadně používat a nasazovat ve společnostech, které se zabývají vývojem softwaru. Nejvíce u společností, které nabízejí hotová produktová řešení.

Důvody k použití průběžné integrace

Mezi hlavní důvody k použití průběžné integrace a nasazení integračního serveru nebo prostředí patří:

  • Vysoká chybovost ve zdrojových kódech.
  • Nalezení chyb je časově a kapacitně náročné
  • Tvorba nových buildů je složitý proces
  • Tvorba buildu je každodenní záležitost
  • Nepořádek ve verzování jednotlivých buildů
  • Nedostatečný technický dohled nad softwarovými projekty
  • Nepořádek v úložišti zdrojových kódů (CVS, SVN, Git)

Základní principy

Použití centrálního úložiště zdrojových kódů

Každý softwarový projekt obsahuje hodně různých souborů, na kterých může pracovat hodně různých lidí. Proto je doporučeno použití úložiště zdrojových kódů (anglicky repository).

Diagram centrální repository zdrojových kódů

To zajistí konzistenci všech souborů a zároveň zálohu každodenní práce na centrálním úložišti. Většina takových systému (CVS, SVN) má v sobě funkce jako je verzování, historie souborů, spojování kódu a informace o změnách. K pokročilejším funkcím takových systémů patří i globální přehled změn a globální reportování toho, kdo úložiště zdrojových kódů nejvíce využívá, kdo byl naposledy přihlášený, která část zdrojových kódů se nejvíce upravuje a jiné.

  • Z výše uvedeného diagramu vyplývá hlavní výhoda centrálního úložiště zdrojových kódů:
    • Funkcionalita a pravidla jsou nastavené centrálně.
    • Každý uživatel může jak nahrávat jednotlivé soubory, tak stahovat nejnovější verze.
    • Možnost centrálních záloh
    • Verzování jsou řešené na globální úrovni a automaticky
  • Mezi nevýhody patří:
    • Potřeba přísné disciplíny celého týmu
    • Větší náročnost na přenos dat
    • Závislost na centrálním systému

Automatizace buildu

Každá kompilace a vydání nové verze je složitý proces, který vyžaduje kompilaci zdrojových kódů, kopírování a přesouvání souborů, nastavování, registrace DLL a přesun výsledného instalačního balíčku na určené místo. Proto je určitě dobré použít některý z nástrojů, který tento proces usnadní a automatizuje. Mezi takové nástroje patří nejznámější z nich Cruise Control (případně Cruise Control .NET). Tento nástroj je open source a slouží k automatizaci celého procesu buildu. Hlavní výhoda je v tom, že pokud se udělá drobná úprava, tak se nemusí ručně (složitě) vytvářet build. Tento nástroj vše provede za vás. Nejedná se ovšem o jediný nástroj v této kategorii. Jeden takový nástroj je vyvíjen i v České republice pod názvem easyCIS. Zde je krátký seznam nejznámějších.

  • AnthillPro
  • Apache Continuum
  • Automated Build Studio
  • BuildBot
  • CABIE
  • dříve Hudson dnes Jenkins
  • Team Foundation Server

Automatizace testování

Pokud proběhl úspěšně build, tak to nemusí znamenat, že program pracuje správně (ať už technologicky nebo logicky). Proto je dobré využívat automatické testování. Jedná se o napsání funkcí, které otestují funkčnost reálných funkcí a procedur. K těmto účelům se používají softwarové nástroje jako je NUnit na C# nebo JUnit na Javu. Více na stránce testování softwaru. Základním principem je to, že vývojář změní pohled na programování a nejdříve může napsat testy, kterými má funkce projít a potom samotnou funkci. Unit testing je metoda, která je ve světě vývoje software čím dál tím více prosazována a vede k efektivnějšímu vývoji a podpoře [3].

Kontrola kvality kódu

Pro rychlejší a efektivnější změny je nutné kontrolovat kvalitu zdrojového kódu. Například jestli kód obsahuje dostatek komentářů, jestli se používají funkce a zbytečně se nekopírují stejné věci. Tyto kontroly urychlí nejen samotné vydání nové verze, ale i zvýší rychlost aplikace. Ve společnostech, které se zabývají vývojem software se používají většinou vlastní předpisy a nástroje na kontrolu kódu, které mohou obsahovat následující předpisy:

  • Definice pojmenování metod, tříd a funkcí
  • Definice komentářů
  • Definice pojmenování visuálních kontrolek
  • Délka pro prvky metoda, třída, funkce
  • Definice a užití proměnných

Zpřístupnění poslední verze

Pokud je to možné, tak by měl k výslednému buildu mít přístup co nejvyšší okruh lidí, aby mohli poslední verzi otestovat i použít. Integrační servery disponují funkcí, která dokáže výslednou otestovanou verzi zpřístupnit na FTP server nebo na jiné úložiště.

Hlavní výhody průběžné integrace

  • Rychlé nalezení chyb ve zdrojovém kódu
  • Automatická kontrola kódu
  • Přehled všech členů týmu o stavu buildu
  • Přehledné verzování jednotlivých verzí
  • Rychlý přístup k poslední verzi aplikace
  • Ušetření času při kompilaci a vydání nové verze
  • Ušetření testovacích kapacit při využití automatického testování

Postup při nasazení průběžné integrace

  • Vyberte si úložiště zdrojových kódů
  • Nastavte pravidla pro používání úložiště
  • Logujte všechny dostupné informace z úložiště
  • Při programování prosaďte používání automatických testů
  • Vydefinujte standardy kvality kódu
  • Nainstalujte a používejte integrační server
  • Nastavte pravidla verzování
  • Nastavte nasazení softwaru (deployment)

Související články

Reference

  1. Paul Duvall, Steve Matyas & Andrew Glover Continuous Integration: Improving Software Quality and Reducing Risk (2007, ISBN 0-321-33638-0)
  2. FOWLER, Martin. Continuous Integration.
  3. http://msdn.microsoft.com/en-us/library/aa292197(VS.71).aspx Unit Testing

Externí odkazy

  • Logo Wikimedia Commons Obrázky, zvuky či videa k tématu průběžná integrace na Wikimedia Commons
  • Anthillpro – Oficiální stránky nástroje Anthillpro
  • Comparison of continuous integration software (Wikipedia)
  • Continuum – Oficiální stránky nástroje Continuum
  • Automated Build Studio – Oficiální stránka nástroje Automated Build Studio
  • BuildBot Archivováno 6. 12. 2010 na Wayback Machine. – Oficiální stránky nástroje BuildBot
  • CABIE Archivováno 1. 3. 2011 na Wayback Machine. – Oficiální stránky nástroje CABIE
  • Hudson – Oficiální stránky nástroje Hudson
  • Jenkins – Oficiální stránky nástroje Jenkins
  • Team Foundation Server – Oficiální stránky nástroje Team Foundation Server
  • Martin Fowler – Continous Integration – Originální článek jednoho ze zakladatelů pojmu průběžná integrace
  • Průběžná integrace a CruiseControl.NET – Český článek o využití integračního serveru Cruise Control .NET
  • easyCIS – Oficiální stránky českého nástroje easyCIS
  • Cruise Control .NET – Oficiální webové stránky produktu Cruise Control .NET
  • PHP Under Control – Průběžná integrace (integrační server) pro PHP