nav line

Výhody kontinuální integrace a automatizovaného deploymentu z pohledu webové integrace

Jakkoli volba konkrétních nástrojů podporujících implementaci principu kontinuální integrace do organizace zabývající se vývojem není nijak spojena s kontinuální integrací jako takovou, v dalším výkladu se přidržíme terminologie verzovacího systému Git, verzovacího workflow Git flow a principů sémantického verzování.

Koncept kontinuální integrace

V organizaci, kde probíhá vývoj projektů či produktů většího rozsahu v týmu, vývojáři zpravidla pracují na jednotlivých částech zadání („features“ nebo „hotfixes“), které je nutné systematicky spojovat do jednoho celku projektu a přitom zachovat integritu (funkčnost) již existujícího díla. Kontinuální integrace spočívá v průběžném provádění úkonů integrace zdrojového kódu, testování, sestavení a nasazení v reakci na každou vývojářem odevzdávanou změnu zdrojového kódu projektu a to za využití nástrojů na podporu vývoje a testování dodržováním stanoveného postupu automatizovaně.

Systém kontroly verzí zdrojového kódu

Úhelným kamenem nasazení kontinuální integrace v organizaci je důsledné použití verzovacího systému na VEŠKERÝ kód projektů, a to ideálně vč. provozní konfigurace (s výjimkou konfigurací specifických pro konkrétní cílové běhové prostředí) a konfigurace databáze ve smyslu definice datových struktur - v případě relačních databází DDL* příkazů, v případě jiných typů úložišť pak jiných popisných souborů, obvykle ve formátu XML nebo JSON).

(* Data Definition Language – jazyk pro popis datových struktur (typicky databázových tabulek)

Vhodné je též v úložišti verzovat nejen programový a konfigurační kód samotných projektů, ale rovněž meta soubory, které napomáhají řídit jednotně proces vývoje a integrace, tedy např. jednotnou konfiguraci integrovaného vývojového prostředí týmu, soubory řídící sestavení projektu (viz. dále) a soubory tento proces konfigurující (konfiguraci sestavení projektu).

Verzovací systémy se obecně dělí na centralizované (CVCS) na bázi architektury server-client a distribuované (DVCS) nevyžadující serverovou službu neboť jim postačí obecně jakékoliv síťově přístupné souborové úložiště. Mezi centralizované VCS patří CVS, SVN (Subversion) či SourceSafe, mezi distribuované např. Git či Mercurial, přičemž zejména Git zaznamenal nejen ve světě open source v posledních letech obrovské rozšíření.

Jednotné úložiště zdrojových kódů (central source code repository)

Jednotné úložiště zdrojových kódů představuje síťové místo či lépe službu, která řeší:

  • hosting – fyzické umístění repositářů kódu použitého verzovacího systému,
  • centralizaci vyvíjeného kódu pro odevzdávání a kontrolu,
  • nastavení bezpečnosti (omezení přístupu ke konkrétním repositářům určitým uživatelům či lépe uživatelským skupinám),
  • kontrola kódu,
  • napojení nástrojů pro spolupráci na vývoji projektu.

Využitím cloudové služby odpadá režie spojená s udržováním vlastního řešení jednotného úložiště. Naopak při využití vlastních hardwarových prostředků zůstává kód uvnitř infrastruktury organizace a může tak být považován za bezpečněji uložený (pomiňme přitom fakt, že statisticky dochází nejvíce k úniku informací právě uvnitř firemní síťové infrastruktury). Technickým aspektem pro volbu typu provozu služby může být i rychlost připojení, kdy je dostupnost služby umístěné ve vnitřní síti firmy řádově vyšší než u externích služeb.

Centralizace přináší výhody jak pro vývojáře tak manažerské role zainteresované do projektu. Vývojáři mají jedno cílové místo pro převzetí aktuálního kódu projektu a následné odevzdávání práce a zůstává jim tak prostor pro soustředění na jejich stěžejní specializaci, kterou je produkce funkčního kvalitního kódu. Na druhé straně mají manažersky zaměření pracovníci jasně dané místo, kde si mohou kdykoliv kontrolovat průběh vývoje projektu.

Na odevzdávání kódu projektu typicky navazuje jeho kontrola. Odevzdání práce pak může nabývat podobu žádosti o přijetí souboru změn (commitů) v kódu projektu (tzv. pull request), kdy nemůže vývojář přímo ovlivnit verzi projektu ve vzdáleném repositáři, ale jím navrhovaná změna musí projít kontrolou kvality (code review). Vlastní kontrola kódu má jednak rozměr kontroly zodpovědnou osobou a dále se pro kontrolu odevzdávaného kódu využívají automatizované testy. Podrobněji níže v kapitole Automatizované testování a kontrola kódu.

Výše uvedené součásti vývoje projektu je výhodné ne-li přímo nutné řešit pomocí specializovaných existujících služeb/nástrojů a to ve smyslu hostované (on-demand) služby nebo aplikace, kterou nainstalujeme na vlastní infrastrukturu a provozujeme tzv. on-premise. Hostované služby představuje Github a Bitbucket, kde má organizace k dispozici webové uživatelské rozhraní pro:

  • pohodlnou správu bezpečnosti,
  • řízení pull requestů,
  • code review,
  • zobrazení historie a
  • možnost integrace na další služby (pro trackování požadavků, automatizovaný deployment aj.)

Nástrojem pro řešení na vlastních hardwarových prostředcích může být pro Linux Stash (on-premise obdoba cloudové služby Bitbucket), GitWeb, Gitolite nebo pro Windows Bonobo Git Server či GitStack.

Systém pro balíčkování a řízení závislostí - packaging and dependency management (PDM) tool

V rámci vývojové infrastruktury vedle určení jednotného úložiště zdrojových kódů vyvstává potřeba úschovy a organizace balíčků již sestaveného kódu ať již v rámci organizace nebo nezávisle mimo ní popřípadě i zabalíčkovaného zdrojového kódu, který se nemění – týká se skriptovacích aplikačních prostředí a/nebo distribuce kódu pro potřeby funkce code assist ve vývojovém prostředí (IDE) a nutnost definovat jasně závislost kódu projektu na těchto balíčcích. Je tedy nutné použít nástroj, který umožňuje konfiguračně definovat potřebné závislosti zdrojového kódu (tedy různé potřebné frameworky a knihovny pro běh aplikace) a dát výsledné sestavené aplikaci podobu distribuovatelného balíčku. Zatímco v některých aplikačních platformách je použití tohoto nástroje neodmyslitelné (např. Apache Maven nejen pro Java based projekty, Ruby Gems pro Ruby či NPM Node.js/Javascript based projekty) ve světě webového vývoje na platformě PHP je jeho existence v podobě nástroje Composer stále relativní novinkou a řada open source projektů s ním stále ještě nepočítá, přesto se však jeho použití stále více prosazuje.

Každý PDM nástroj přináší do vývoje obvykle následující vlastnosti (features)

  • Definuje konfigurační soubor projektu pro definici závislostí vč. repositářů, v nichž lze závislé balíčky opatřit, a další podmínky pro sestavení aplikace, obvykle ve formátu XML nebo JSON
  • Definuje formát/podobu balíčku opakovaně použitelného zdrojového či sestaveného kódu (dle aplikační platformy) vč. jeho meta definice (analogie konfigurace projektu)
  • Disponuje obvykle jedním či více vlastními veřejnými repositáři v nichž jsou zpřístupněny balíčky s populárním volně šiřitelným (open source) kódem (v případě nástroje Composer je to služba Packagist)
  • Nástroj pro příkazovou řádku (CLI) pro řízení životního cyklu projektu v návaznosti na zvolený archetyp, typicky tedy
    • vytvoření adresářové struktury projektu v návaznosti na zvolený aplikační framework či architekturu
    • stažení všech potřebných závislostí pro vývoj (zdrojové kódy pro code asistenci v IDE) či běh projektu
    • aktualizace stažených závislostí při změně konfigurace
    • sestavení (zabalíčkování) s možností nahrání do běhového prostředí (aplikace) nebo úložiště balíčků (knihovny); v rámci sestavení pak vykonávání řady na sobě závisejících úkonů

Nástroj kontinuální integrace (Continuous Integration tool - CI)

Nástroj kontinuální integraci zajišťuje veškeré automatizovatelné úkony v rámci realizace CI procesu a to za využití resp. ve spolupráci s výše popsanými nástroji pro správu zdrojového kódu a řízení závislostí, jeho sestavení a balíčkování. K dispozici je řada nástrojů jak open-source tak komerčních, z nejznámějších uveďme

Některé jsou zaměřeny na použití ve spojení konkrétní aplikační platformou, jiné jsou platformě neutrální. CI nástroj lze provozovat jak v tradičním on-premise modelu tak je využívat jako cloudovou službu. On-premise nasazení může být v některých případech nutností, typicky pokud jsou úložiště zdrojového kódu a/nebo cílová běhová prostředí pro nasazení aplikace umístěna v privátní síti organizace a nelze je z důvodu bezpečnostních politik zpřístupnit cloudové službě.

Základní vlastností CI nástroje je definice parametrizovatelných úloh, které se mohou rozpadat do jednotlivých dílčích kroků. Úloha následně může být vykonána buď spuštěním přes webové uživatelské rozhraní CI nástroje, nebo přes jeho API vyvoláním na základě události v jiném systému (typicky). Úlohy též mohou být spojovány do vyšších logických celků. Do značné míry tak CI nástroje opakují principy samostatných sestavovacích command line nástrojů typu Ant, Maven nebo Phing, se kterými se též mohou doplňovat (krok v úloze sestavení může volat sestavovací nástroj řízený sestavovacím konfiguračním souborem (build config file), který může být součástí verzovaného kódu projektu nebo je na něm nezávisle uložen na CI serveru).

Automatizace sestavení

Sestavením se rozumí činnost, která stažením zdrojového kódu a konfiguračních souborů vč. definice závislostí a kódu touto definicí požadovaného pro překlad a/nebo běh projektu vytvoří podobu projektu spustitelnou v běhovém prostředí a to obvykle v podobě balíčku, může se však jednat pouze o pracovní (workspace) adresář vytvořený na CI serveru pro další použití. V závislosti na zvolelené aplikační technologii může být součástí sestavení překlad, v případě PHP se obvykle jedná o instalaci resp. aktualizaci sestavené podoby projektu nástrojem Composer. Automatizované sestavení bývá obvykle prováděno CI nástrojem na základě změny (nového commitu) v některé z hlavních větví v repozitáři zdrojového kódu projektu. Úspěšné automatizované sestavení projektu pak může být vstupem (triggerem) navazujícího automatizovaného nasazení. V případě produktu (aplikace či knihovny) obvykle automatizovaným sestavením CI proces končí (na CI serveru je vyskladněn hotový balíček pro další použití).

Automatizace nasazení

Na základě úspěšného automatizovaného sestavení a otestování projektu může CI nástroj ihned, nebo nezávisle v samostatné úloze přistoupit k automatizovanému nasazení do cílového prostředí. V rámci vývoje je třeba jasně definovat a jednotně chápat soubor prostředí, které jsou v organizaci k dispozici pro nasazování projektu. Tato prostředí vychází obvykle z životního cyklu projektu.

  • Interní test pro nasazování aktuální (HEAD) podoby projektu ve vývoji (develop). V případě, že je pro vývoj webových projektů využíváno sdílené serverové prostředí (což je v případě PHP vývoje ve větších organizacích rozšířená praxe), potom se interní test realizuje obvykle v tomtéž serverovém prostředí, v jakém vývojáří vyvíjejí, čímž má zajištěno ekvivalentní běhové podmínky, jako lokální instance projektu vývojářů. S interním testem pracuje vývojový tým (vč. testerů a interního product ownera, delivery managera či projektového managera dohlížejícícho kontinuálně na postup vývoje) .
  • Preview, někdy též UAT či prostě testovací prostředí. Do preview se obvykle nasazuje z release nebo hotfix větve zdrojového kódu projektu, případně může být definována samostatná preview větev, do které vývojáři mergují změny, které chtějí automatizací nasazení projektu do preview prostředí vystavit. S preview prostředím pracuje a zapracované změny v něm ověřuje (akceptuje) primárně zadavatel (product owner).
  • Production nebo-li live prostředí.

Automatizovaný deployment snižuje ne-li přímo nepotřebuje vstupy vývojářů do běhových prostředí v rámci procesu nasazování, což pozitivně přispívá ke stabilnímu chování aplikací.

Automatizované testování a kontrola kódu

Testy lze podle časového okamžiku spuštění rozdělit do skupin pre-commit (před odevzdáním), pre-deploy (před nasazením) a post-deploy (po nasazení do cílového prostředí).

Pre-commit testy

Kontrola syntaktické validity a kódovacích konvencí (formátování, dokumentace zdrojového kódu)

Pre-deploy testy

Pre-deploy testy se vztahují ke zdrojovému kódu a lze je vykonat ještě před sestavením případně v jeho rámci (tedy typicky poté, co jsou připraveny všechny potřebné závislosti balíčkovacím nástrojem). Tyto testy mohou být spouštěny v návaznosti na integraci změn v kódu v systému pro správu zdrojového kódu do některé z hlavních větví (develop, master) hlavního repositáře projektu. V závislosti na povaze testu resp. strategii integrace mohou být spuštěny ještě předtím, než bude změna do větve integrována (tzv. pre-commit) nebo až po ní (post-commit).

  • Spouštění unit testů implementovaných v rámci projektu pro otestování jednotlivých funkcí (typicky za využití PHPUnit frameworku)

Post-deploy testy

Post-deploy testy lze vykonat pouze v návaznosti na úspěšné automatizované nasazení, neboť vyžadují aplikaci běžící v cílové prostředí. Jedná se typicky o:

  • Automatizované uživatelské testy vytvořené v nástroji Selenium IDE a spouštěné CI nástrojem v prostředí Selenium server
  • Integrační testy ověřující funkčnost systému

Automatizace testování z něj činí samozřejmou a stále přítomnou součást vývojového procesu. Oproti tradičnímu ad-hoc prováděnému (či pomíjenému) testování může CI proces přítomnost testů vyžadovat a zároveň nutí na jejich selhání tým reagovat (ať už opravou zdrojového kódu, nebo aktualizací testu v návaznosti na implementované požadované funkční změny).

Hlavní přínosy nasazení kontinuální integrace do procesu výroby webových řešení

Automatizace jednotlivých opakujících se úkonů sestavení na nasazení aplikace eliminuje výskyt chyb spojených s jejich manuálním vykonáváním. Navíc automatizovaný proces je vždy popsán minimálně ve formě konfiguračních souborů či konfiguračních nastavení nástrojů, které jej vykonávají, přičemž tyto konfigurace spravuje omezený okruh osob (pouze role CI/deployment manager) a navíc i na ně lze obvykle aplikovat version control systém a mít tak v celém týmu pod kontrolou, kdy kdo takovou metadefinici procesu změnil.

Automatizované vykonávání testů zajišťuje kontinuálně probíhající testování projektu v návaznosti na probíhající změnu na úrovní zdrojového kódu (typicky tedy integraci commitu do některé z hlavních větví projektu) nebo i nezávisle na ní (post-deploy testy mohou průběžně ověřovat integritu běžící aplikace ve zvoleném cílovém běhovém prostředí)

Kontinuálně probíhající proces sestavovaní a nasazování zajišťuje, že v návaznosti na vývojáři odevzdanou práci a workflow projektu mapující jednotlivé vývojové fáze na cílová běhová prostředí jsou v těchto prostředích vždy aktuální otestované verze projektu. Automatizované nasazování zároveň usnadňuje mimořádné opravné prostředky, tj. dovoluje snadno nasadit předcházející verzi v případě, že navzdory proběhnutým automatizovaným popř. i manuálním testům projekt vykazuje v daném prostředí problémy.

Koncept kontinuální integrace se přirozeně vhodně doplňuje s agilními, iterativními metodologiemi softwarového vývoje (Scrum).

Nástroj kontinuální integrace shromažďuje a dle potřeb/pravidel organizace dále distribuuje informace o výsledku automatizované úlohy dostupnými informačními kanály (e-mail, instant messaging příp. SMS zprávy). Tím přispívá k informovanosti každého člena vývojového týmu i zájmových osob stojících vně týmu (manager vývoje, projektový management, product owner) o průběhu procesu řízené změny ve webovém projektu.

Užitečné odkazy

Ohodnoťte článek

Výhody kontinuální integrace a automatizovaného deploymentu z pohledu webové integrace

Diskuse

Lorem ipsum

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