Wikipedie

Průběžná integrace

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ů

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.

Proces průběžné integrace a role integračního serveru

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

editovat

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

editovat

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

editovat

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

editovat

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ů:
  • 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

editovat

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.

Automatizace testování

editovat

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

editovat

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:

Zpřístupnění poslední verze

editovat

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

editovat

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

editovat

Související články

editovat

Reference

editovat
  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

editovat
Citováno z „https://cs.wikipedia.org/w/index.php?title=Průběžná_integrace&oldid=20947124“