UNICORN COLLEGE. Bakalářská práce

Transkript

1 UNICORN COLLEGE Katedra Informačních technologií Bakalářská práce Automatizovaný deployment PHP aplikací Automated deployment of PHP applications Autor práce: Jakub Kohout Vedoucí práce: Ing. Tomáš Holas 2015 Praha

2

3

4 Čestné prohlášení Prohlašuji, že jsem svou bakalářskou práci na téma Automatizovaný deployment PHP aplikací vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím výhradně odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou také uvedeny v seznamu literatury a použitých zdrojů. Jako autor této bakalářské práce dále prohlašuji, že v souvislosti s jejím vytvořením jsem neporušil autorská práva třetích osob a jsem si plně vědom následků porušení ustanovení 11 a následujících autorského zákona č. 121/2000 Sb. V dne (Jakub Kohout)

5 Poděkování Děkuji vedoucímu bakalářské práce Ing. Tomáši Holasovi za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce. Dále bych chtěl poděkovat Ing. Václavovi Purchartovi za odbornou konzultaci.

6 Automatizovaný deployment PHP aplikací Automated deployment of PHP applications 5

7 Abstrakt První část práce popisuje obecné vlastnosti Continous integration procesu a automatizovaného deploymentu. Druhá část se zabývá praktickým výběrem vhodných řešení, jejich zkombinování a vylepšení pro potřeby malého vývojového týmu, který používá agilní metodiku. Po přečtení této práce by měl být čtenář vybaven teoretickou znalostí Continuous integration procesu a automatizovaném deploymentu. Zároveň by si měl z další části odnést praktický návod, jak oba procesy zavést ve své firmě a vyvarovat se problémům, kterými si musela projít firma, ve které pracuje autor této práce. Klíčová slova: Continous Integration, Automatizovaný deployment, Databázové migrace, Symfony2, Gitlab, Travis, Phing, Webistrano Abstract First part of this thesis describes common features of continuous integration process and automated deployment. Second part of this thesis is about choosing proper technologies; their coming together and improving them to suit the needs of a small agile development team. After reading this thesis you will have knowledge about continuous integration and automated deployment and be able to implement both processes, without facing the same issues as the author. Keywords: Continuous Integration, Automated Deployment, Database Migrations, Symfony2, Gitlab, Travis, Phing, Webistrano 6

8 Obsah 1 Úvod Continuous integration Compile Příprava fixtures Centrální testovací databáze Generování nových fixtures Centrální testovací databáze a dogenerované fixtures pro testy Statická analýza kódu Unit testing PHPUnit [4] Nette\Tester [5] Deploy Funkční testy a Integrační testy Notifikace DevOps Report Deployment Příprava release Verzování aplikací Sémantické verzování Manuální deployment Bezvýpadkový deployment Atomicita Migrace dat Cache soubory Protokoly používané deployment FTP Bezpečnost Nespolehlivost SCP + SSH RSync [14] Databázové migrace Manuální migrace

9 3.6.2 Automatické migrace Zajištění integrity databáze Migrace nahoru a dolu Zápis migrací Existující software pro deployment Shell script Ukázka jednoduchého deployment scriptu Git hooky [16] Capistrano Webistrano Minimální požadavky pro provoz Existující software pro continuous integration Travis CI Cena Podpora GIT hostingu Software as a service Podpora pro PHP Podpora dalších služeb a systémů Úroveň reportingu Konfigurace Travis CI enteprise GitLab CI Podpora GIT hostingů GitLab GitLab Cena Hosting Podpora pro PHP Podpora dalších služeb a systémů Úroveň reportingu Konfigurace Deployovací a CI managment v praxi GitLab Instalace GitLab CI Instalace Kompilace pomocí Phingu

10 7.1 Proč Phing nemůže dělat kompletní deployment Proč mít build konfiguraci v rámci projektu Build od nuly oproti inkrementálnímu buildu Mít Phing nainstalovaný v systému nebo v rámci projektu Konfigurace Phingu Properties Targets Webistrano Konfigurace na serveru Konfigurace aplikačního serveru Zabezpečení privátního klíče Spuštění SSH-Agenta Automatické spouštění agenta Test, zdali tunelování funguje Automatické skripty pro založení nové stránky Zajištění bezvýpadkového deploymentu [28] Nginx Apache Vytvoření projektu a dostupná konfigurace Vytvoření nového projektu Stages Konfigurační volby Základní konfigurace Symfony2 konfigurace Deployment Oprávnění a přístupová práva Další dostupné příkazy Rollback Databázové migrace Promazání cache Rozšíření specifická pro projekt Napojení na NewRelic Konfigurace Ukázka

11 8.10 Definice vlastních šablon a úkolů Nedostatky Závěr Původní stav Po implementaci continuous integration a automatizovaného deploymentu Budoucí rozšíření Conclusion Original situation After company implemented continuous integration process and automated deployment Future extension Příloha A Přiložené CD Webistrano Server scripts Symfony2 Demo Fixtures Phing Build Testy Doctrine Migrations Seznam obrázků Seznam zdrojů

12 1 Úvod Programovací jazyk PHP byl původně navržený pro jednoduché webové stránky. Postupem času se z něj stal jeden z nejpopulárnějších jazyků pro webové stránky a s tím narostla mnohonásobně i komplexnost aplikací. Deployment jednoduché webové aplikace o pár zdrojových souborech se dá provést vskutku jednoduše. Na druhou stranu aplikace velkého rozsahu, jejichž zdrojové soubory mají několik tisíc souborů s celkovou velikostí několika set megabytu, které potřebujeme nahrát na několik aplikačních serverů, vyžadují mnohonásobně složitější proces. Pokud aplikace svojí povahou vyžaduje co největší dostupnost a kvalitu, tak celému procesu přidáváme ještě další úroveň komplexnosti. Potřebu pro automatizovaný deployment PHP aplikací dokazuje už jenom to, jaké velké webové portály používají PHP. Na českém internetu se může jednat například o: Slevomat.cz, Csfd.cz, Denik.cz, Uloz.to, Lupa.cz V celosvětovém měřítku jsou ještě mnohonásobně větší portály: Wikipedia.org, Facebook.com, Taobao.com, Flickr.com Automatizovaný a bezvýpadkový deployment PHP aplikací je ale jenom část celého procesu. Jedním z moderních trendů v softwarovém businessu je proces, jemuž se říká continuous integration. Tento proces předchází deploymentu a doplňuje mezery při efektivním vytvářením softwaru. Práce se snaží popsat ideální výběr technologií a zavedení continuous integration procesu ve firmě s následujícími parametry. Tým je malého rozsahu, přibližně 10 lidí. 11

13 Firma má vlastní serverovou infrastrukturu postavenou na linuxových distribucích. Serverová infrastruktura se skládá z několika aplikačních serverů, tzv. cluster. Firma má všechny aplikace napsané v PHP a aplikačním frameworku Symfony2. Tým má rozsáhlou znalost verzovacího systému GIT. Firma se snaží používat software, který je zdarma, aby minimalizovala náklady. Firma preferuje opensource řešení, před komerčním řešením. 2 Continuous integration Continuous integration (CI), nebo-li méně používáný český výraz průběžná integrace je moderní trend využívaný hlavně agilními týmy. Hlavní myšlenka continuous integration se opírá o tvrzení, že software by měl být po každé změně prověřen, že je spustitelný a funkční. Víceméně to znamená, že se vytvoří build i několikrát denně. Dalším důležitým prvkem continuous integration je rychlé generování výsledků. Čím dříve se vývojáři dozvědí o chybné verzi, tím jednodušší je ji opravit. 1 Jednotlivé kroky CI, Vlastní tvorba 12

14 2.1 Compile Vývojář připraví změny, vyzkouší si na své lokální stanici, že vše funguje, a odešle commity do vzdáleného repozitáře, kde budou k dispozici ostatním. CI systém stáhne zdrojové soubory do připravené složky. Nainstaluje všechny potřebné závislosti pomocí Composeru a spustí například Phing, který se postará o všechna potřebná konfigurační nastavení. 2.2 Příprava fixtures Většina projektů potřebuje pro svůj běh databázové úložiště. Rozhodně není možné spouštět testy na produkční databázi. To znamená, že je třeba testovací databáze. Existují tři strategie: Centrální testovací databáze Existuje produkční databáze a testovací databáze, která je odvozená z té původní. Například se data z produkční databáze anonymizují (klíčové údaje se změní na náhodné hodnoty. Například se nahradí jména klientů, čísla kreditních karet apod.) a přenesou do testovací databáze. V momentě, kdy připravuje CI build, tak si tuto databázi zkopíruje. Výhody Nízké náklady na přípravu. Stačí jen zkopírovat databázi a spustit několik UPDATE příkazů pro klíčová data. Máme skoro tu samou databázi na produkci i pro testy, co se týče objemu. Tedy naše testy jsou spouštěny na obdobném počtu dat jako na produkci a můžeme tak připravit výkonnostní testování. Dále máme v testovací databázi případné chyby z minulosti (nekonzistence dat). To má za následek, že testy prověří aplikaci i na nekonzistentní data a máme menší pravděpodobnost, že naše aplikace přestane fungovat produkčním nasazení. Vhodné pro rozsáhlé projekty, které už mají několik let za sebou a tudíž je jejich databáze rozsáhlá a prošla mnoha migracemi. Nevýhody Není dobré v testech spoléhat na data z databáze. Je totiž možné, že tato data jsou neaktuální a testy by mohly být false positive. 13

15 2.2.2 Generování nových fixtures Při každém spuštění testů se vytvoří databáze dle aktuálního schéma. Pro Symfony projekty s modelovou vrstvou nad Doctrine2 se nejčastěji používá DoctrineFixturesBundle [1]. Pro vytvoření fixures pomocí tohoto nástroje stačí přidat do build scriptu php app/console doctrine:fixtures:load Užitečným pomocníkem pro generování fixtures je knihovna Faker [2]. Této knihovně předáme název entity, kterou chceme vygenerovat, a kolik jich chceme. Knihovna vygeneruje instance entity a pokusí se uhádnout, jaká data by měla obsahovat. Ukázka tohoto přístupu je k dispozici v příloze Fixtures. Výhody Toto řešení má výhody zejména ve fázi, kdy projekt ještě není v produkci a tudíž nepotřebuje řádné databázové migrace. Stačí pokaždé vygenerovat nové schéma a nahrát do něj výchozí hodnoty. Kód je testovaný oproti databázi, která obsahuje opravdu data, proti kterým je napsaný test. Je možné použít například SQLite databázi, pokud je projekt malý a nechceme kvůli tomu zatěžovat databázové servery vytvářením dalších testovacích databází. Nevýhody Je velice pracné udržovat všechny fixtures aktuální. Obzvláště pro různé konfigurační tabulky v databázi Centrální testovací databáze a dogenerované fixtures pro testy Tento způsob je kombinací obou předchozích případů, kdy máme výchozí schéma v podobě vygenerované databáze a do ní dogenerováváme fixtures, které později použijeme v testech. 14

16 Například systém potřebuje testovat systém objednávek. Nebude tedy spoléhat na to, že už nějaké objednávky v systému jsou, ale vytvoří si nové objednávky a nad těmi spustí testy. 2.3 Statická analýza kódu Statická analýza kódu probíhá tak, že zkoumá kód, jak je napsaný, ale nespouští jej. Většinou zkoumá tyto problémy: Hledání syntaktických chyb (například chybějící závorka, středník apod.). Hledání sémantických chyb (například sčítání čísla a textového řetězce). Chyby vůči specifikovanému coding standartu (například různé formátování kódu). Volání, která nejsou možná pro verzi knihoven, které projekt používá. Bezpečnostní prohřešky (neošetřený vstup / výstup). Volání, která nejsou v definované verzi PHP dostupná (například použití $this v closure v PHP 5.3). Zapomenuté testovací příkazy (nechtěný výpis testovacích proměnných apod.). Detekce mrtvých kusů kódu. 2.4 Unit testing CI systém spustí všechny předepsané unit testy. Cílem této práce není poskytnout vyčerpávající informace o unit testingu, proto jen zmíním, jak by měl správný unit test vypadat. Testy by na sobě měly být nezávislé. Testy by měly být spustitelné opakovaně. Unit testy by měly testovat jednu jedinou věc a ta by měla být co nejmenší. Unit test by se měl zaměřit na co nejmenší jednotku a tu otestovat. Pokud má testovaná třída nějaké závislosti, měly by být zamockované. Pro mockování v PHP existuje velká řada nástrojů, jedním z nejznámějších je Mockery [3]. Testy by měly kontrolovat i chybové stavy. V prostředí PHP lze použít následující frameworky pro testování. 15

17 2.4.1 PHPUnit [4] Nejpoužívanější Framework pro testování na světě v PHP prostředí. Je to robustní Framework, který umí spoustu věcí, což je současně i jeho nevýhoda. Testovací třída musí mít předepsaný formát a musí dědit od konkrétní třídy PHPUnit_Framework_TestCase Nette\Tester [5] Český projekt, populární hlavně ve střední Evropě. Hlavními výhodami jsou [6]: Rychlost, protože se scripty pouští paralelně. Testovací skripty jsou samostatně spustitelné soubory. 2.5 Deploy Abychom mohli aplikaci podrobit dalším druhům testů, tak ji nejprve musíme připravit do spustitelného stavu, nebo-li aplikaci nahrát na nějaké dostupné umístění i pro uživatele. 2.6 Funkční testy a Integrační testy Psaní funkčních testů je v Symfony2 frameworku vskutku velice jednoduché. Symfony2 již v sobě obsahuje nástroje pro funkční testy, takže není problém s nimi otestovat např. volání controlleru. Ukázka funkčního a integračního testu je v příloze Testy. 2.7 Notifikace DevOps Kdy poslat notifikaci je hodně závislé na velikosti týmu, zvolených testech, jejich podrobnosti a úrovni reportingu. Pokud by byla zvolená intenzita notifikací příliš vysoká, tak by DevOps měli tendenci notifikace nečíst a rovnou je archivovat, případně mazat. Příkladem může být, pokud budeme posílat notifikaci o každém provedeném buildu, nezávisle na výsledku testovaní, tak se může stát, že DevOps dostanou stovky ů denně. V takovém případě by opravdu ve většině případů notifikace nečetli a rovnou je mazali. Což je potom úplně k ničemu, protože mohou smazat i notifikaci, která vyžaduje pozornost. 16

18 Z mé zkušenosti je nejlepší mít nastavena velmi přísná pravidla na testování, statickou kontrolu kódu a následně zasílat pouze informace o defektních buildech. Pokud máme defektní aplikaci, tak je důležité o tom informovat kompetentní osobu. Kdo je kompetentní osoba záleží na velikosti týmu a rozdělení rolí. Kompetentní osobou může být například ten, kdo poslal do společného repositáře defektní commit, či ten, kdo začlenil defektní větev do další release verze. Nejčastěji jsou notifikace formou u, ale je možné zaintegrovat i sofistikovanější systém, například pomocí služeb typu Pagerduty [7]. Pagerduty je služba, která obecně řídí koho notifikovat v případě problému. Hlavní výhoda spočívá v tom, že ví, kdo je nejvhodnější osoba v daný moment pro řešení předem definovaného problému. Například pokud někdo odjede na dovolenou nebo má celý den vytížený schůzkami, tak mu pravděpodobně ani nemá smysl posílat report o nefunkčním buildu. Zároveň PagerDuty uchovává jasný seznam problémů, jejich stav a odpovědnou osobu. 2.8 Report Report je posledním krokem v kolečku povinností správného CI procesu. Veškeré výsledky kompilace, testování, uživatelského testování musí být začleněny do reportu o aktuální verzi aplikace. Report by měl být dostatečně podrobný, ale také přehledný, aby se dalo jednoznačně určit, jestli je daná verze v pořádku, nebo obsahuje chyby. 3 Deployment 2 Deployment pipeline, autor: Continuous integration Jsme v situaci, kdy máme díky CI otestovanou aktuální verzi aplikace a chtěli bychom ji dostat do produkce. Nejprve se podíváme do CI systému, vytáhneme si report na verzi, 17

19 kterou chceme deploynout. Pokud je report v pořádku, tak můžeme přeskočit k manuálnímu otestování. CI systém by nám měl umožnit vyzkoušet si aplikaci a provést manuální testování. Jak takové testování probíhá, záleží na povaze aplikace a na testovací strategii. Součástí manuálního testování může být například ověření, že grafické rozhraní vypadá dobře a funguje v pořádku. Je to z toho důvodu, že grafická a uživatelská přívětivost se těžko testuje automaticky. 3.1 Příprava release Jedním z best practises pro práci s GITem je práce s větvemi. Tedy vývojář připravuje veškeré změny ve své vlastní větvi a v momentě, kdy je připravena, tak požádá senior vývojáře o code review a o začlenění jeho kódu do vývojové větve. Po začlenění jakékoliv nové změny se správce aplikací 1 musí rozhodnout, jestli je změna tak závažná, aby se z ní hned udělal repase, nebo počká na nějaké další změny. Pokud se rozhodne, že připraví nový release, tak pomocí CI serveru ověří, že je aplikace funkční, dělá to, co má, a následně pomocí GIT merge spojí vývojovou větev s tou produkční. 3.2 Verzování aplikací Potřebujeme nějakým způsobem označit různé verze aplikace v přípravě releasu. Do této doby se identifikovaly verze pouze za pomocí hashe commitu (každý commit v GIT repositáři má svůj vlastní unikátní identifikátor označovaný jako commit hash ). Ovšem je vskutku nepraktické, abychom označovali verze aplikace pomocí tohoto hashe, protože není jasně vidět kontinuita (jenom z pohledu na seznam verzí bychom nevěděli, jak jdou po sobě). Mnohem výhodnější a doporučovaný způsob označování verzí je použití čísel, která se zvyšují s každou verzí. Toto je pravděpodobně nejpoužívanější přístup u většiny aplikací a je k vidění všude okolo nás. 1 Jedná se pouze o roli, klidně do ní může být dosazen opět ten samý seniorní vývojář, který začlenil změny do vývojové větve. 18

20 Formát se obvykle zapisuje jako major.minor.patch[.build]. Většinou je vidět jen major a minor označení. Patch se drží interně v development týmu. Ovšem například Adobe Flash veřejně uvádí i patch verze, takže příklad verze je [8]. Existují samozřejmě i výjimky, například Linuxová distribuce Ubuntu označuje verze jako year.month z doby vydání. Například tedy verze byla vydaná v dubnu Jde prostě o rozhodnutí firmy Sémantické verzování Autorem semantického verzování je Tom Preston-Werner. Tento způsob verzování se zavedl zejména pro opensource projekty, aby bylo jasně rozeznatelné, jak velké změny byly provedeny od poslední verze. Nejdůležitější pravidla jsou: [9] Jakmile je jednou verze publikovaná, tak se její obsah nesmí změnit. Jinými slovy, jakmile uveřejníte verzi, tak už ji nesmíte změnit. Pokud nová verze aplikace obsahuje BC break (backward compatible break neboli porušení zpětné kompatibility), tak se musí zvýšit major verze. Například pokud změníme API nebo upravíme aktuální funkce, tak musíme zvýšit verzi. Pokud nová verze aplikace obsahuje zpětně kompatibilní změnu, tak se musí zvýšit minor verze. Například pokud do API přidáme nějaké nové funkcionality. Patch měníme v situacích, kdy neměníme venkovní chování. Využívá se například na opravu chyb apod. Je třeba dávat pozor na situaci, že i když se nezmění venkovní rozhraní, tak je možné připravit BC break. Může se jednat o situaci, kdy se změní chování aplikace, na které jiná aplikace spoléhala, nebo například opravíme chybu, která je v aplikaci dlouho a ostatní aplikace na to spoléhají. 3.3 Manuální deployment Manuální deployment je prakticky to nejjednodušší, co si můžete představit, prakticky vše se musí udělat vždy ručně. Pro jednoduché aplikace, které obsahují pár souborů, není problém otevřít FTP spojení a nahrát nový soubor na produkční server ručně. Ovšem většina moderních aplikací je značně rozsáhlejších a vyžaduje provedení spousty kroků. 19

21 Hlavními nedostatky manuálního deploymentu jsou: [10] DevOps tráví čas na rutinních opakujících se úkolech. Je možnost lidské chyby a tudíž i defektní aplikace. Dokumentaci k aplikaci nemusí vždy být aktuální. Na dokumentaci se totiž musí podílet jednak DevOps team, za druhé vývojový tým. Jsme závislí na manuálním testování. Pokud DevOp zapomene něco vyzkoušet, tak aplikace může být defektní. Obvykle máme více prostředí (vývojové, testovací a produkční) a aplikace má své vlastní specifické nastavení pro každé z nich. Manuální deployment obvykle provádí jedna osoba, která má zkušenosti a znalosti o dané aplikaci, prostředí a postupu. Pokud tato osoba má dovolenou nebo ukončí svoji činnost ve firmě, firma je v problému. Nový člen vývojového týmu má mnohonásobně více práce s rozběhnutím projektů jen za pomoci dokumentace. Otestovat manuální deployment jde pouze tak, že to celé vyzkoušíme. Otestovat automaticky deployment jde levně a rychle. Manuální deployment není skoro vůbec auditovaný a je obtížné hledat případný problém. 3.4 Bezvýpadkový deployment Managment firmy obvykle vyžaduje, aby aplikace běžela nonstop bez výpadku a pravděpodobně nebude ochotný tolerovat několika minutové výpadky vždy, když se správce aplikací rozhodne odeslat novou verzi aplikace do produkčního prostředí Atomicita Atomicita, jinými slovy nedělitelnost, znamená, že se nějaká činnost buďto povede celá, nebo nepovede vůbec. Neexistuje žádný stav mezi tím. Webová aplikace potřebuje pracovat na verzi 1 nebo na verzi 2, ale rozhodně není schopná fungovat, pokud by měl k dispozici pouze polovinu souborů potřebných k běhu. V takovém případě riskujeme, že aplikace bude nekonzistentní, nebude fungovat a může dojít i k trvalé ztrátě dat. 20

22 Jedním z možných řešení je novou verzi nahrát do jiné složky na serveru a v momentě, kdy je vše připraveno, tak přepnout webový server do této nové složky Migrace dat Při migraci dat, či změně databázového schéma existuje riziko, že deployment klidně na několik hodin zamkne klíčové databázové tabulky a aplikace bude po celou tu dobu absolutně nedostupná. Například pokud aplikace loguje každé uživatelské přihlášení do databáze do speciální tabulky a vývojář, či databázový specialista se rozhodne, že přidá do nové verze aplikace migraci, která změní typ jednoho sloupečku, tak na vývojové či testovací databázi migrace proběhne rychle, protože tyto databáze mají obvykle jenom několik tisíc záznamů o přihlášení uživatelů. Bohužel pokud není součástí continuous integration procesu i výkonnostní testování, tak zajistíme problém s touto migrací až v produkčním prostředí, kdy se pokusíme provést deployment této migrace nad miliardami záznamů. Vzhledem k povaze daného požadavku změnit typ sloupce a množství záznamů dojde k uzamknutí tabulky pro zápis a žádný z klientů se již nepřihlásí, dokud tato migrace nedoběhne. Při přípravě migrací si musí být databázový specialista velice jistý tím, co dělá, a není na škodu zaimplementovat výkonnostní testování do continuous integration procesu. Samozřejmě není vždy možné se vyhnout složitějším migracím a potom je třeba zajistit plánovanou odstávku systému. Existuje i řešení, jak zajistit bez výpadkovou migraci za předpokladu, že máme dvě synchronizované databáze vedle sebe a podporují transakční zpracování. Aplikace komunikuje pouze s databází č. 1, v tento moment zastavíme synchronizaci mezi databází č. 1, č. 2 a veškeré transakční logy začneme ukládat například do souboru. Na databázi č. 2 spustíme potřebnou migraci a počkáme, než doběhne. V momentě, kdy migrace doběhne, tak aplikujeme všechny uložené transakční změny na databázi č. 2 a přepneme na ni veškerý provoz. Následně jen sesynchronizujeme obě databáze s tím, že databáze č. 2 je označena jako ta hlavní. 21

23 3.4.3 Cache soubory Velké aplikace obvykle používají nějaké dočasné úložiště pro často používaná data či výpočty, které jsou časově náročně, aby je nemusely vždy znovu získávat. Problémem je to, že pokud provedeme deployment nové verze aplikace, tak nikdo nemůže zaručit, že se ten výpočet nezměnil. Tudíž je vhodné všechna úložiště s těmito typy dat okamžitě promazat. Proto je nutné, aby aplikace či úložiště těchto dat vystavily ven nějaké API, které to umožní. Zároveň je také nutné počítat s cache úložištěm, které nemusí být pod naší kontrolou. Například se může jednat o různé CDN sítě, či cache na straně klienta. Zejména se tento problém řeší u statických souborů, které posíláme klientovi. Je proto vhodné vždy statické soubory minifikovat 1 a jako název výsledného souboru použít hash obsahu, tím zajistíme, že klient vždy dostane aktuální verzi. 3.5 Protokoly používané deployment FTP Tento způsob je z hlediska historie jedním z nejznámějších a dodnes hojně využívaným. Výhoda tohoto řešení je jeho jednoduchost. Protokol FTP byl navržen v roce 1985 [11]. FTP využívá pro svůj běh dva porty, po jednom posílá řídící signály a na druhém portu posílá data. Jedná se o port 20 a 21, konkrétní využití těchto portů záleží na nastavení Bezpečnost Největším problémem tohoto protokolu je bezpečnost, ve standardech FTP protokolu RFC 2577 [12] jsou tyto problémy zmíněny. 1 Minifikace je proces, kdy se snažíme zmenšit objem dat o nepotřebná data. Například při minifikaci javasciptu se z kódu vypustí všechny nepotřebné mezery, komentáře, nové řádky apod. Zároveň se několik souborů spojí do jednoho jediného a to ušetří rychlost načtení těchto dat v momentě, kdy si o ně klient požádá. 22

24 Konkrétně se jedná o tyto útoky: Brute force attacks Bounce attacks Packet capture (sniffing) Port stealing Spoof attacks Username protection Pravděpodobně ten nejnebezpečnější spočívá v útoku packet capturing, což se dá volně přeložit jako odposlouchávání paketů. Útok využívá toho, že FTP není šifrovaný protokol a útočník může odposlechnout jednak samotná data, tak jméno a heslo, pomocí kterého se potom může přihlásit na server a udělat škodu. Tuto zranitelnost řeší protokol sftp popřípadě SCP, jež bude zmiňován dále Nespolehlivost Protokol FTP funguje dobře, pokud se serverem pracuje vždy jeden uživatel. Bohužel toto v reálných podmínkách není možné zařídit a obvykle se na server pojí mnoho uživatelů současně. V takovémto momentě protokol přestává být spolehlivý. Obzvláště při nahrávání velkého počtu souborů se zvyšuje šance, že nějaký soubor selže a vývojář potom bude velice složitě dohledávat soubor, který se nezkopíroval celý [13]. Z těchto důvodů není vhodné používat pro deployment protokol FTP. Bohužel v mnoha případech se jedná o jedinou metodu, obzvláště pokud potřebujete jednoduchý a levný webhosting SCP + SSH SSH je protokol pro vzdálený přístup k příkazové řádce na serveru. SCP je protokol pro přenášení souborů po SSH spojení. Obrovská výhoda této metody je spolehlivost a bezpečnost (veškerá data i příkazy jsou šifrovány). 23

25 Díky tomu, že je možnost se přihlásit přes SSH, tak není problém měnit obsah souborů na vzdáleném serveru, využívat symlinky a další pokročilé metody. Jenom samotné využití daného protokolu by byla ruční metoda, ale díky výhodám tohoto protokolu jej později budeme potřebovat v automatizovaných postupech jako jednu součást. Nevýhoda tohoto řešení spočívá v tom, že administrátor serveru obvykle nechce dávat SSH přístup zákazníkům, protože ti jednak získávají pohodlí s prací na jejich aplikaci, ale na druhou stranu přináší velké riziko, že neodborným zásahem způsobí škodu na samotné konfiguraci serveru (smazáním důležitého souboru, složky aj.). Tímto se dostáváme k dalšímu problému a tím je pro vývojáře pokročilá znalost serverového prostředí. Na serveru není žádné grafické prostředí a vývojář je odkázán jen na příkazovou řádku RSync [14] RSync je protokol, který je navržen na synchronizaci souborů po síti. Je navržen jako náhrada za protokol SCP. Obrovská výhoda tohoto protokolu spočívá v tom, že se přenáší jen změny a nikoliv všechny soubory znovu. Uvedu příklad, za použití SCP by se všechny zdrojové soubory musely vždy znovu všechny nahrávat na server. To může být klidně i stovky megabytů a pro síť by to bylo velice zatěžující. Naopak RSync se podívá, jaké soubory se liší od těch na serveru, a nahraje jen tyto změněné soubory. Výhoda tohoto postupu spočívá v nízké režii na síti, ale problémem může být rollback. Pokud vývojář nahraje špatnou verzi aplikace nebo něco jiného selže, potřebuje se co nejrychleji vrátit k předchozí verzi. Což v tomto případě znamená, aby si ve verzovacím nástroji stáhl aktuální verzi a tu opět nahrál na server, což může zabrat klidně desítky minut u větších změn. Tedy desítky minut, kdy je aplikace zcela nefunkční. 24

26 3.6 Databázové migrace Většina aplikací potřebuje někam ukládat data. Obvykle proto jako úložiště dat používá databázi. Problém je v tom, že i databázové schéma a data se postupem času musí měnit spolu s aplikací. Aplikaci máme ve verzovacím systému a můžeme se tedy kdykoliv vrátit k jakékoliv verzi. Musíme tedy ještě do verzovacího systému dostat databázové schéma Manuální migrace Nejprimitivnější implementace migrací je nějakým způsobem sdílet sql příkazy. Sdílení může být za pomoci dokumentace nebo verzovaných souborů s SQL dotazy v repositáři. Jediná výhoda tohoto řešení je asi jen prakticky nulová investice do přípravy prostředí pro migrace. Nevýhody manuálních migrací: Musíme uchovávat v dokumentaci seznam již aplikovaných migrací, jinak nebudeme vědět, které migrace ještě chybí aplikovat. Extrémně náchylné na lidskou chybu. Pokud vývojář špatně připraví migraci, případně ji vůbec nevytvoří, tak vzniká chyba, která se pravděpodobně odhalí až při deploymentu do cílového prostředí. Pro manuální migrace není možné připravit testy. Není možné tento proces zautomatizovat a zahrnout jej do continuous integration procesu. Není možné takové migrace testovat Automatické migrace Pro automatické migrace je vhodné využít existující knihovnu. Výhody automatické migrace: Nemusíme se starat o to, které migrace už byly aplikovány a které ne. Knihovna může generovat migrační skripty automaticky. Například porovnáním schéma databáze a ORM schéma v aplikaci. Bohužel to nikdy není ultimátní řešení, vygenerované skripty stejně musíme projít ručně a finálně upravit. Automatické migrace je možné zahrnout do continuous integration procesu a tím pádem mít i automatické testy. 25

27 Informace o provedených migracích je možné ukládat do tabulky v databázi. Výhoda tohoto způsobu je v tom, že databáze ví, v jakém je stavu, bez toho, aby měla přístup k souborovému systému. Nevýhoda tohoto postupu je v tom, že musíme mít aktivní připojení do databáze pro zjištění, jestli nechybí nějaká migrace. Transakce a z části i naše migrace se opírají o princip ACID, což je akronym následujících slov. Atomic Atomicita, každá migrace se buďto provede úplně celá bez chyb, nebo se neprovede vůbec. Toto je věc, kterou musíme v migracích řešit a je detailně popsána v následující kapitole. Consistent Konzistence, data po provedení migrace neporušují žádná integritní pravidla našeho schéma. Pokud by porušovala, tak se migrace nesmí dokončit a musí skončit s chybou. Isolated Izolované, jednotlivé migrace nesmíme spouštět paralelně, ale vždy je musíme spouštět za sebou. Durable Provedená migrace musí být trvale zapsaná v databázi i kdyby celý systém přestal fungovat hned po provedení migrace. Toto je převážně záležitost databáze, v migracích je jen potřeba zajistit, že informace o aplikované migraci je aktualizována ve stejné transakci Zajištění integrity databáze Jedna migrace se obvykle skládá z 1 až N dotazů do databáze. Není možně vždy napsat celou migraci do jednoho databázového dotazu. Pokud ale v rámci jedné migrace máme více než jeden dotaz, tak musíme nějak zajistit, že se buďto provede celá migrace, nebo ne. V žádném případě se nesmí stát, že se provede polovina dotazů a druhá polovina dotazů skončí s chybou. V takovém případě by migrace mohla mít fatální následky. Například pokud bychom chtěli přesunout data a transformovat je do jiné tabulky, tak musíme položit minimálně dva dotazy do databáze. První dotaz je zkopírování dat a jejich transformace do druhé tabulky. Druhý dotaz smaže původní data. 26

28 Pokud napíšeme transformační dotaz s chybou, tak přijdeme o všechna data, protože se neprovede první dotaz na zkopírování a druhý dotaz, který bude následovat, data nenávratně smaže. Tomuto problému se dá zabránit tak, že pokud nějaký dotaz skončí chybou, tak by migrace měla vyhodit výjimku a nepokračovat dál. Výjimka nám ovšem řeší jenom polovinu problému. Následující příklad popíše problém, který výjimka neřeší. Chceme připravit novou tabulku, která bude obsahovat konfigurační nastavení naší aplikace. Musíme tedy připravit dva dotazy. V prvním dotazu vytvoříme tabulku a v druhém ji naplníme. Pokud se povede vytvořit tabulku, ale nepovede se vložit data, tak s největší pravděpodobností nebude fungovat zbytek aplikace, protože se provedla pouze část migrace. Výjimka sice vyskočila, ale první dotaz už se provedl. Řešením tohoto problému je použití databázových transakcí. Transakce funguje tak, že databázi řekneme Begin transaction ( začínám transakci ), pak posíláme dotazy, které se sice aplikují ale jenom v rámci tohoto připojení. V momentě, kdy jsou všechny dotazy provedeny, tak migrace pošle Commit ( hotovo ), až teď databáze aplikuje všechny předcházející dotazy a jsou trvale uloženy v databázi. Pokud by jakýkoliv dotaz skončil chybou a byla vyhozena výjimka, tak musí migrace poslat Rollback ( vrať změny zpátky ). Databáze v takovém momentu zahodí veškeré poslané dotazy a tváří se, že se nic nestalo Migrace nahoru a dolu Pokud se řeknou migrace, tak si většina lidí představí pouze aktualizaci databáze směrem nahoru, tedy aktualizaci na novější verzi. Problém ovšem je, že občas musíme jít i zpět a nemusí jít jenom o fatální důvody typu rollbacku celé produkční aplikace. Kupříkladu pokud vývojový tým drží pro každý nový use case vlastní větev ve verzovacím systému, tak vývojáři obvykle mění aktuální větve velice často. Pokud se chce přepnout z jedné feature větve do druhé, tak musí nejprve vrátit stav databáze do společného momentu obou větví a až potom aplikovat nové migrace. 27

29 K tomuto je právě vhodné v každé migraci definovat cestu nahoru, tedy aktualizace, a pak také cestu zpátky, jak dané aktualizace vzít zpět. S tímto ovšem přichází řada problémů se zpětnou kompatibilitou. Obzvláště napsat migraci tak, aby šla vždy vrátit, je hodně těžké. Zde je popis několika situací, které mohou nastat v cestě nahoru a jak k nim správně zapsat cestu zpět. Mazání dat tohle je relativně jednoduchá úloha, při cestě nahoru je nemazat, ale jen přesunout do nějaké dočasné tabulky. V migraci dolu zase naopak přesunout data z dočasné tabulky to té správné. Pozor na problém s UNIQUE sloupečky. 1 Aktualizace dat - pokud měníme data na nějakou konkrétní hodnotu, tak nám nezbude nic jiného než opačný dotaz zapsat do migrace na cestě dolu. Toto funguje pouze pro omezené množství změn, pokud bychom například měnili data způsobem, že by tento krok již nešel vrátit zpět, tak je musíme při cestě nahoru zapsat do nového sloupečku a všechna data zkopírovat. Změna schéma databáze tohle může být datově nejnáročnější úkol, pokud potřebujeme nějaký sloupeček smazat, tak musíme zálohovat prakticky celou tabulku. V případě, že chceme sloupeček přidat, tak při cestě dolu jej zase můžeme odebrat, zde je třeba se několikrát ujistit, jestli opravdu ta data v mazaném sloupečku nepotřebujeme. V žádném případě se nejedná o úplný výpis problémů, ale o velice jednoduchou ukázku, že napsat správně databázové migrace není vůbec jednoduchý úkol Zápis migrací Jak zapsat migraci záleží na použité knihovně, může se jednat o textový soubor s příponou sql nebo se může jednat o třídu v PHP. Sql soubor nabízí pouze velice omezené možnosti, obvykle se zapisuje pouze migrace nahoru, nikoliv dolu. Mnohem propracovanější migrace nabízí Doctrine Migrations. Ukázka jak řesit migrace pomocí doctrine migrations je v příloze Doctrine Migrations. 1 Mezi tím než spustíte migraci dolů, tak se objeví nová data v původní tabulce. Tudíž při přesunu dat zpátky do produkční tabulky, může nastat situace, že už tam je řádek se stejným UNIQUE klíčem, který se snažíte vložit. 28

30 Jak je vidět z ukázky, migrace umožňují obě formy cest. Každá migrace se zapisuje jako samostatná třída. Důvodem, proč použít Doctrine Migrations, je (pokud používáte Doctrine jako ORM) možnost porovnávat aktuální schéma databáze oproti entitám a vygenerovat z toho migraci. Samozřejmě je možné pouze vygenerovat migraci směrem nahoru a nikoliv dolu. Alternativa k Doctrine Migrations je například projekt Phinx [15] 3.7 Existující software pro deployment Různých knihoven a softwaru existuje hodně. Není jeden nejlepší, ale každý se hodí na něco jiného. Kritéria pro výběr správného nástroje pro deployment: Počet projektů čím více projektů máte, tím by měla být větší páka k tomu požít automatické řešení. Velikost týmu pro dva lidi v týmu nemusíme řešit bezpečnost tak jako pro 50 lidí. Počet serverů pro jeden server je mnohonásobně jednodušší provést deployment než pro cluster skládající se z několika serverů. Technologie projektu nemá smysl se pokoušet deploynout aplikaci napsanou v Javě pomocí nástrojů, které nativně podporují PHP či Ruby On Rails. Serverová platforma software pro deployment musí být kompatibilní s operačním systémem, který provozujeme na serveru. Serverové prostředí pokud už na serveru používáme technologii pro konfigurační management typu Chef nebo Puppet, tak stojí za zvážení, jestli jej nepoužít pro deployment aplikací místo hledání další aplikace Shell script Shell script je pravděpodobně ta nejjednodušší forma automatizovaného deploymentu. Implementace může být formou primitivního scriptu, který jen zkopíruje zdrojové soubory z repozitáře do složky, kam je směrovaný virtualhost webového serveru. Naopak je možné mít i velice komplexní script, který nejprve celý projekt otestuje, provede statickou analýzu kódu, rozkopíruje jej na všechny servery, spustí kompletní build a spustí databázové migrace. 29

31 Vzhledem k tomu, že nejsou vymezeny žádné hranice a záleží jenom na tom, kolik je tým ochotný investovat energie do přípravy deployment scriptů, tak není možné aplikovat standardní kritéria na tento typ projektu. Teoreticky není ani nutné, aby se jednalo o Shell script, může být napsán v jakémkoliv jazyce, záleží jen na technologii, co je k dispozici na serveru. Výhoda shellu spočívá v tom, že je nativní na Linuxovém operačním systému, nemá omezení na dobu běhu scriptu a je mnohonásobně rychlejší než třeba PHP. Pro zjednodušení ale uvádím jako název Shell script. Výhody shell skriptu: Oproti ručnímu přístupu značně eliminujeme riziko lidské chyby. Obrovská rozšiřitelnost. Script může provádět prakticky cokoliv, co si naprogramujeme. Nejsme vázáni na technologii. Můžeme použít jakýkoliv interpret, který je k dispozici. Nevýhody shell skriptu: Prakticky vše si musíme naprogramovat, případně pospojovat kusy kódu, které nalezneme na internetu. Neexistuje grafický výstup. Návrh toho scriptu musí provést zkušený odborník, jinak se vystavujeme riziku, že bude deployment sice funkční, ale bude mít nečekané vedlejší efekty (například bude špatně zálohovat nebo bude deployment vždy s nepatrným výpadkem) Ukázka jednoduchého deployment scriptu Předpokládá tuto strukturu složek * home ** project domovská složka projektu *** update složka, která obsahuje všechna potřebná data pro deployment **** update.sh script který provádí deployment **** repository dočasná složka, kam se kopírují zdrojové soubory z repozitáře **** backups složka, která obsahuje zálohy minulých verzí *** www domovská složka pro samotný projekt 30

32 Ukázkový script provádí tyto operace: Vytváří zálohu aktuální verze aplikace Aktualizuje aplikaci Instaluje závislosti pomocí Composeru Spouští databázové migrace Zasílá notifikaci NewRelic o provedeném deploymentu. Update.sh #!/bin/bash # exports current version from GIT repository echo Cloning repository cd /home/project/update/repository; git pull origin master; echo OK #current files backup echo Backing up files filename=back_$(date +%Y%m%d) tar cvzf /home/project/update/backups/$filename /home/project/www echo OK # uses rsync to copy the new version to the production environment echo Synchonizing production dir with current master branch... rsync -r -t -v -u /home/project/update/repository/* /home/project/www echo OK echo Install dependencies via composer cd /home/project/www && composer install --no-scripts --verbose --prefer-dist --no-dev echo OK echo Running Database Migrations php /home/project/www/bin/console "Doctrine Migrations migrate" echo OK echo "Sending notification to New Relic" curl -H "x-api-key:insert_your_key " -d "deployment[app_name]=projectname" echo Project update completed 31

33 3.7.2 Git hooky [16] GIT umožnuje mít několik různých verzí aplikace vedle sebe, označuje se to jako branch neboli větev. GIT hook deploy funguje na tom principu, že na serveru máme větev production a na ni máme navěšený tzv. hook. Hooků je několik, ale pro deployment nás zajímá konkrétní post-update. Pokaždé, když se na server do větve production nahraje nová verze (nový commit), tak se spustí právě tento hook, což je uložený script. Daný script už může být ten samý, jako jsme uvedli v kapitole Ukázka jednoduchého deployment scriptu. Automatizovaný script Repozitář zdrojových kódů Produkční server Nová verze aplikace Vývojář 3 Schéma nasazení aplikace pomocí GIT hooku, zdroj: vlastní tvorba 32

34 Využití GIT hooku má téměř ty samé nedostatky jako shell skript, ale přináší řadu výhod. Automatizace není třeba se přihlašovat na vzdálený server a ručně spouštět script, čímž se vystavujeme riziku, že osoba provádějící deployment udělá chybu. Jednoduchá možnost deploymentu jakéhokoliv commitu bez toho abychom nějakým způsobem manipulovali s konfigurací na serveru, můžeme provést deployment jakéhokoliv commitu. Rychlý ale stále rizikový rollback pokud potřebujeme rollback, tak stačí vzít jiný commit a provést jeho deployment. Musíme ovšem pamatovat na riziko spojené s databázovými migracemi. Osoba, která provádí deployment, nemusí mít přístup na server u málo kritických projektů, či u testovacích projektů, nemusíme vytvářet přístupy na aplikační servery například pro externisty, kterým chceme dát možnost deploymentu, ale nikoliv aby měli přístup do VPN či přímo na server. Přehled o tom, jaká verze je aktuálně v produkci jednoduše z GITu zjistíme, jaká verze je aktuálně na serveru a kdo ji tam dal Capistrano Capistrano je pokročilý nástroj pro nasazení softwaru na server. Jedná se o konzolovou aplikaci, která je nainstalována na počítači vývojáře, či serverového správce. Klíčovou součásti jsou tzv. recepty, což jsou předpřipravené skripty, kterými nahráváme aplikaci na server. Recept může být například deploy, provést migrace na databázi, restartovat cache apod. 33

35 Repozitář zdrojových kódů Zdrojové kódy Nasazení produkční verze Nasazení testovací verze Produkční server Testovací server Capistrano Spouští recepty Vývojář 4 Schéma nasazení aplikace pomocí Capistrana, zdroj: vlastní tvorba Nevýhoda tohoto řešení spočívá v tom, že vývojář musí mít na svém počítači nainstalováno Capistrano, musí s ostatními sdílet recepty a vše je třeba řešit přes příkazovou řádku. Zároveň také musí mít sám přístup na všechny servery a oprávnění ke spuštění všech příkazů v receptu, čímž se firma vystavuje bezpečnostnímu riziku Webistrano Webistrano je grafická nástavba nad Capistranem. Webistrano byl projekt založený a vyvíjený společností Peritor consulting. Firma byla odkoupena společností Amazon AWS, která se rozhodla nadále nerozvíjet tento nástroj pro deployment, i přestože se jedná o jeden z nejpoužívanějších nástrojů pro deployment (GitHub ukazuje 278 forků). Naštěstí Webistrano je pouze grafická nástavba nad stále aktuálním projektem Capistrano a doplněna o několik dalších knihoven pro rozšíření podpory. 34

36 Samotné Webistrano má pouze podporu pro Ruby on Rails a nikoliv podporu pro PHP projekty. Podpora pro projekty postavené nad PHP lze přidat začleněním projektů třetích stran, jako je například Capifony, případně je nutné dopsat si rozšíření samostatně Minimální požadavky pro provoz Projekt vyžaduje Linuxový server, popřípadě OS X server. Windows není podporovaný. Dále je potřeba na serveru mít nainstalované tyto knihovny: Ruby verze nebo (verze a vyšší nejsou podporovány) Rubygem verze SQL databáze MySQL / PostgreSQL GIT Detailní popis je k nalezení v kapitole 8 Webistrano. 3.8 Existující software pro continuous integration Continous integration jako knihovna, či jako samostatně běžící software by měl umožňovat provedení všech kroků, tedy od kompilací buildu, přes testy, až po vygenerování reportu. Většina aplikací to umí, ovšem s rozdílnou mírou podpory a komplexnosti celkově. 35

37 Hlavní kritéria pro výběr Continous integration serveru: Cena. Podpora GIT hostingu. Pokud hostujete repozitáře v GitLabu nebo Bitbucketu, tak nebudete mít k dispozici všechny CI servery. Jestli potřebujete hostovat CI server u sebe na serveru, například kvůli bezpečnosti nebo vám nevadí spolehnout se na cizí servery. Podpora programovacího jazyku. Pokud daný CI server nenabízí podporu vašeho programovacího jazyka, tak nejspíš nebude ten vhodný. Podpora dalších služeb. Moderní aplikace obvykle závisí na dalších externích systémech, se kterými komunikují pomocí API. Je třeba, aby tyto systémy byly k dispozici i v testovacím prostředí na CI serveru. Například se může jednat o message brokera RabbitMQ či o různé typy databází. Úroveň reportingu. Například takový Jenkins má mnohonásobně propracovanější report než třeba GitLab CI. Počet různých rozšíření. Pro doplnění chybějící funkcionality. Rozšiřitelnost. Zda-li je možné systém doplnit o dodatečné funkcionality Travis CI Travis je pravděpodobně jeden z nejznámějších CI serverů pro PHP. Jedná se opensource projekt, skládající se momentálně z těchto částí [17]: travis-api travis-build travis-core travis-cookbooks travis-hub travis-listener travis-logs travis-support travis-tasks travis-web travis-worker 36

38 Cena Travis je k dispozici zdarma pro open source projekty na adrese Placená verze pro skryté repozitáře (není k nim přístup bez authentizace a autorizace) je k dispozici na adrese Cena se odvíjí od počtu pracovních instancí, které mohou běžet ve stejnou dobu. Například pokud víme, že pro provedení celého kolečka CI buildu potřebujeme 10 minut a během běžného pracovního dne náš tým vyprodukuje 150 commitů, tak bychom vygenerovali takové množství práce, které by jedna pracovní instance zpracovávala 25 hodin čistého času. To by znamenalo, že náš tým bude ustavičně čekat na CI report. Pro takový tým by bylo optimální mít přibližně 5-10 pracovních instancí Podpora GIT hostingu Bohužel Travis podporuje pouze repozitáře, které jsou hostované na GitHubu a není možné použít jiný systém. Momentálně se ani neplánuje budoucí podpora pro další systémy jako je Bitbucket [18] apod Software as a service Travis je primárně poskytovaný jako SaaS (software as a service), tedy nepotřebujete vlastní server, protože je Travis provozovaný na jejich serverech. To má obrovskou výhodu v tom, že se nemusíte starat o aktualizace, dostupnost služby apod. Nevýhoda spočívá v tom, že se musí platit měsíční poplatky za pronájem služby. Další nevýhoda spočívá v bezpečnosti, protože vaše zdrojové kódy budou k dispozici třetí straně Podpora pro PHP Travis nabízí širokou paletu verzí PHP, dokonce je k dispozici i ještě nevydané PHP7 a nightly build PHP. Co vidím jako velkou výhodu Travisu je, že umí otestovat jeden build vůči několika různým verzím PHP. Toto se hodí zejména při přípravě knihoven, u kterých nevíme, kdo všechno je použije. 37

39 Podpora dalších služeb a systémů Pro každý build se startuje virtuální systém, který není sdílený s nikým dalším, tzn. je určený pouze pro tento build [19]. Toto řešení má nevýhodu v rychlosti, protože nastartování instance chvilku trvá. Ale na druhou stranu obrovská výhoda je, že je možnost instalace čehokoliv. Například Travis má momentálně podporu pouze pro MySQL 5.5, pokud chceme novější verzi, tak si ji musíme sami doinstalovat. Ale to není vůbec žádný problém. V samotném základu má Travis aktuálně podporu pro tyto služby [20]: MySQL PostgreSQL MongoDB CouchDB Redis Riak RabbitMQ Memcached Cassandra Neo4J ElasticSearch Kestrel SQLite Úroveň reportingu Travis v základní konfiguraci posílá notifikaci pomocí kompetentní osobě v těchto případech: Pokud je daný build defektní a testy neproběhly úspěšně. Pokud byl build defektní a nyní je už opravený. 38

40 Travis se neomezuje jenom na , umožňuje posílat notifikaci skrz tyto kanály [21]: IRC Campfire Flowdock HipChat Sqwiggle Slack Webhook Co se týče složitějších reportů, například graf úspěšnosti buildů, to Travis momentálně neumí. Travis obecně neumí generovat žádné grafické výstupy, hlavní výstup je pouze textový záznam o proběhnutém buildu. Tato funkcionalita se obvykle doplňuje službami třetích stran, například pro code coverage lze použít Coveralls [22] Konfigurace Veškerá konfigurace se provádí pomocí souboru.travis.yml, který je umístěn v kořenovém adresáři daného repozitáře. Pomocí tohoto souboru jsme schopni kompletně připravit celý build, aniž bychom museli sáhnout do potenciální webové administrace. Travis totiž ani žádnou administraci projektů nemá. 39