Automatizace Procesu Vývoje Na Platformě Xamarin

Masarykova univerzita Fakulta informatiky

Automatizace procesu vývoje na platformě Xamarin

Diplomová práce

Bc. Tomáš Šmíd

Brno, jaro 2019 Prohlášení

Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Bc. Tomáš Šmíd

Vedoucí práce: doc. Ing. RNDr. Barbora Bühnová, Ph.D.

i Poděkování

Rád bych poděkoval doc. Ing. RNDr. Barboře Bühnové, Ph.D. za velmi vstřícné a odborné vedení a za poskytnutí velmi cenných rad a připomínek především při psaní textové části práce. Rád bych také poděkoval Ing. Martinu Vídeňskému co by odbornému konzultantovi za cenné rady a připomínky při realizaci praktické části. Nakonec bych rád poděkoval společnosti A-WebSys spol. s r.o. za velmi vstřícný a otevřený přístup při řešení jakéhokoliv problému spojeného s vy- pracováním této diplomové práce.

ii Shrnutí

Cílem této práce je automatizovat procesy mobilního vývoje na plat- formě Xamarin, a to zejména s důrazem na oblasti verzování, kontroly kvality a testování zdrojového kódu ve firmě A-WebSys spol. s r.o. V první části práce jsou představeny termíny spojeny s automatizací procesů a platformou Xamarin. Ve druhé části práce je popsána ana- lýza vývojových procesů a všech dalších oblastí potřebných k pocho- pení problematiky a následnému vytvoření návrhu řešení, které je také součástí této části. V závěrečné třetí části práce je představena implementace praktického řešení společně s vyhodnocením, do jaké míry se ho podařilo ve firmě integrovat a jaký je jeho přínos.

iii Klíčová slova

Xamarin, automatizace, CI, CD, DevOps, procesy, Git, GitLab, GitLab CI/CD, GitLab runner, yaml, mobilní vývoj

iv Obsah

1 Úvod 1

2 Procesy a automatizace 3 2.1 DevOps ...... 4 2.1.1 Průběžná integrace ...... 5 2.1.2 Průběžné doručení, průběžné nasazení . . . . .5

3 Platforma Xamarin 7 3.1 Mvvm, MvvmCross ...... 7

4 Analýza 9 4.1 Aktuálně nastavené procesy mobilního vývoje ve firmě ...9 4.1.1 Klíčové ukazatele výkonnosti procesů ...... 12 4.1.2 Vyhodnocení výkonnosti procesů ...... 13 4.2 Verzování kódu ...... 14 4.2.1 Git vs. Subversion ...... 14 4.2.2 Strategie použití nástroje Git ...... 15 4.3 GitLab CI/CD ...... 20 4.3.1 Základní komponenty ...... 21 4.3.2 Požadavky a omezení nástroje ...... 25 4.3.3 Požadavky a omezení na realizaci ...... 25 4.4 Kontrola kvality kódu ...... 26 4.4.1 StyleCop Analyzers ...... 27 4.5 Sestavení a jednotkové testy ...... 28 4.6 Distribuce aplikace ...... 29 4.6.1 Tvorba APK a IPA balíčků ...... 30 4.6.2 Distribuce k živým testerům ...... 31 4.6.3 Distribuce do produkčního prostředí ...... 33 4.7 Sběr dat od klientů ...... 34 4.8 Návrh řešení ...... 35 4.8.1 Distribuce aplikace ...... 38

5 Implementace 40 5.1 Nastavená pravidla pro kontrolu kvality kódu ...... 40 5.2 Skriptovací soubory ...... 41 5.3 Nastavení GitLab CI/CD ...... 49

v 5.3.1 GitLab runner ...... 49 5.3.2 YAML soubor ...... 50 5.4 Překážky k vyřešení ...... 57 5.4.1 Konfigurace nástroje GitLab runner . . . . 57 5.4.2 Práce s NuGet balíčky ...... 58

6 Vyhodnocení 62 6.1 Dosažené výsledky ...... 62 6.2 Srovnání s původním stavem ...... 64

7 Závěr 66

Bibliografie 67

A Přílohy 78 A.1 Verzování ...... 78 A.2 Kontrola kvality kódu ...... 79 A.3 Skriptovací soubory ...... 87 A.3.1 Vstupní parametry ...... 87 A.3.2 Ukázky kódů ...... 90 A.4 Konfigurace ...... 94 A.4.1 YAML soubor ...... 94 A.5 Řešení zásadních překážek ...... 97 A.5.1 Vzájemná kompatibilita .NET platforem . . . . . 97 A.5.2 Převedení formátu Packages.config na Package- Reference ...... 98 A.5.3 Přesun metadat do souboru .csproj ...... 100 A.5.4 Používání přípon u názvů NuGet balíčků . . . . 101 A.5.5 Funkce IncludeReferencedProjects u programu dotnet ...... 102 A.5.6 Nastavení umístění NuGet balíčků ...... 104

vi 1 Úvod

Přesně definované procesy jsou základem správně nastaveného vývo- jového prostředí. K dosažení větší efektivity tohoto prostředí se dnes v maximální možné míře využívá automatizace. Té lze dosáhnout vhodně zvolenými podpůrnými nástroji, které doplňují definované procesy. Nicméně, nasazení a použití těchto ná- strojů k provádění specifikovaných úkolů samo o sobě často nestačí k dosažení zlepšení procesů. Při zavádění automatizace je potřeba také změnit celkovou kulturu organizace. Proces je tvořen několika různými složkami, které se podílejí na dosažení požadovaného výstupu. Proto je potřeba zajistit, aby spo- lupráce mezi jednotlivými složkami byla co nejhladší (viz kapitola 2). A-WebSys spol. s r.o. [62] (dále jen A-WebSys) je společnost, která se ve své dlouholeté historii specializovala především na vývoj inter- netových aplikací v oblasti finančního sektoru. Za sebou má celou řadu úspěšných projektů, a tak se v roce 2017 rozhodla v této oblasti rozšířit svou působnost a zařadit do svého portfolia vývoj mobilních a desktopových aplikací. Pro multiplatformní vývoj musela firma A-WebSys zvolit mnoho nových technologii. Především však pro vývoj zvolila platformu Xama- rin (viz kapitola 3), která umožňuje kód psát v jednom jazyce, kterým je C#, a ten sdílet a použít pro více cílových platforem. A i když při vývoji internetových aplikací kód verzuje pomocí nástroje Subversion, zde se rozhodla přejít k systému Git (viz podsekce 4.2.1). Nakonec pro vývoj na platformě Xamarin vznikl zcela nový tým. Do začátku se firma rozhodla nastavit procesy vývoje především dle zkušeností a postupů používaných při vývoji webových aplikací, protože oblast mobilního vývoje pro ní byla zcela nová a neměla v ní žádné zkušenosti. Současně díky nově používaným technologiím a novým lidem tak zůstává prostor ke zlepšení těchto procesů. Cílem této diplomové práce je seznámit se s procesy vývoje pro mobilní platformy ve společnosti A-WebSys postavené na platformě Xamarin, a to zejména s důrazem na oblasti verzování, kontroly kvality a testování zdrojového kódu, a zjistit, v čem by bylo možné používané procesy zefektivnit. Pro tento účel je vyhrazena celá kapitola 4, která

1 1. Úvod

čtenáře seznámí s aktuálně nastavenými procesy ve firmě a detailně rozebírá jednotlivé důležité části vývojových procesů ať už z pohledu postupů či z pohledu nástrojů, které se buď používají ve firmě, anebo bude nutné je použít za účelem jejich zefektivnění. Důraz je především kladen na použití nástrojů, které jsou volně dostupné. Dalším požadavkem na tuto práci je navrhnout možné řešení na základě informací získaných po seznámení se všemi důležitými body vývojových procesů ve firmě, které zajistí zefektivnění těchto procesů. Návrh řešení se nachází v sekci 4.8. Posledním z požadavků na tuto práci je navržené řešení realizovat, nasadit ve firmě a vyhodnotit, zda se pomocí implementovaného řešení podařilo procesy zlepšit. Popis reálného řešení včetně popisu klíčových překážek, které bylo nutné vyřešit při implementaci, se nachází v kapitole 5. V kapitole 6 je popsáno, do jaké míry se imple- mentované řešení podařilo ve firmě úspěšně nasadit. Popsán je zde také samotný přínos práce.

2 2 Procesy a automatizace

Proces představuje základní kámen žívotního cyklu vývoje software. Definuje co, jak a kdy má být provedeno při vývoji. Staví nazku- šenostech a ověřených činnostech. Součástí procesu jsou role lidí, aktivity, techniky a nástroje, které jsou společně využity k dosažení požadovaných výstupů [51]. Typickými procesy při vývoji software jsou plánování, analýza po- žadavků, návrh, implementace, stabilizace a testování kódu, nasazení do produkčního prostředí a údržba. Jednotlivé pořadí, význam a další vlastnosti těchto procesů určuje konkrétní strategie či model životního cyklu vývoje projektu [52]. Procesy se mohou po nějakém čase stát nevhodnými. Důvodem mohou být například změny strategických cílů organizace či jejich výkonnostní aspekty, které mají finanční dopad. V takovém případě je potřeba procesy upravit a zefektivnit. Před tím, než je možné začít s jejich optimalizací, je potřeba se s nimi důkladně seznámit a popsat jejich současný stav. Na základě zjištěných údajů lze rozhodnout, co je potřeba v pro- cesech zlepšit a dojít k volbě vhodné techniky, která by měla pomoci procesy zefektivnit. Pokud je problém v lidské činnosti, pak je možným řešením napří- klad reorganizace zaměstnanců zapojených do daných procesů, anebo zpřesnění definic jednotlivých rolí. Jako slabý článek procesu se může projevit nepřesné či chybějící definice aktivit, které mají být prováděny. To může vést k zbyteč- nému množství rozhodování a nerovnoměrnému zatížení technických či lidských zdrojů. To vše může vést k snížení výkonnosti procesu a zpomalení celého vývoje. Řešením pro tento problém je zavedení automatizace procesu. Cílem automatizace procesů je urychlit a usnadnit práci rychlým a opakovatelným prováděním konkrétních úkolů a aktivit. Tím se také snižují náklady potřebné k vytvoření požadovaných výstupů a celkově snižuje chybovost. Aby bylo možné procesy efektivně automatizovat, je potřeba kromě vhodně zvolených nástrojů, které konkrétní úkoly budou provádět, zpřesnit jejich celkovou definici, tj. specifikovat jednotlivé role aod-

3 2. Procesy a automatizace povědnosti, aktivity a jejich vlastnosti a využití technik a nástrojů. Především však musí být přesně určeny výstupy těchto procesů. Konceptem, který napomáhá zefektivnění procesů v organizaci, a to včetně využití jejich automatizace, je DevOps (viz sekce 2.1).

2.1 DevOps

Termín DevOps představuje složení dvou slov development a operations. Přesná definice tohoto termínu neexistuje, tzn. že DevOps nelze chápat jako konkrétní metodiku, soubor doporučení, předpisů či přístupů [53]. Cílem DevOps je usměrnit a urychlit nasazení software do pro- dukčního prostředí s důrazem na zlepšení komunikace a spolupráce mezi vývojovým prostředím, tj. například programátory a testery, a provozním týmem, kam patří například experti pro nasazení software do produkce, systémoví či databázoví administrátoři nebo síťoví technici. Důraz je také kladen na učení se ze zkušeností a zpětné vazby z produkčního prostředí [53]. DevOps se nicméně nezaměřuje pouze na oblast vývoje a pro- vozu, ale představuje zastřešující koncept pro všechny oblasti, které se nějakým způsobem podílejí na dodávce software do produkčního prostředí [53]. Aby mohlo být DevOps efektivně v organizaci využito, je potřeba od základu změnit její kulturu, tj. změnit smýšlení lidí, zlepšit jejich komunikaci a vzájemnou důvěru a zaměřit se především na zákazníka. Také je potřeba přesně definovat jednotlivé procesy, které mají usnadnit fungování organizace. Nakonec je potřeba zvolit vhodné nástroje a správně je zorganizovat, aby podporovaly nastavené procesy [53]. V dobře nastaveném prostředí DevOps jsou k vidění například vlastnosti jako výborná komunikace a spolupráce mezi jednotlivými odděleními, sbírá a vyhodnocuje se zpětná vazba z produkčního prostředí, které se neustále monitoruje, vhodným způsobem se kód verzuje a neustále zlepšuje a používá se jak CI, tak CD [55]. Přínos správně používaného DevOps přináší například zlepšení v oblasti spokojenosti zákazníků, schopnosti inovovat a rychle reagovat na podněty a celkovou produktivitu a kvalitu produktu při snížení rizik a zranitelností při vývoji [56].

4 2. Procesy a automatizace

2.1.1 Průběžná integrace Průběžná integrace (dále jen CI1) představuje metodiku vývoje software, při níž je zpravidla při každé provedené změně v kódu nahrané do sdíleného repozitáře, tento kód integrován, kompilován a testován. Vše se provádí v rámci vývojového prostředí [54]. CI se používá pro vývoj, ve kterém členové týmu svou práci často integrují s prací ostatních, tj. minimálně každý den, spíše však několi- krát za den. Každá tato integrace je pomocí automatické kompilace a otestování ověřena, zda provedené změny stále prochází testy a ne- porušují stabilitu projektu [54]. CI používají také vývojové týmy, které pro svou práci využívají postupy hojně využívající automatizaci [54]. Jedním z předpokladů pro úspěšné nasazení a používání CI je, že v případě nalezení chyb při ověřování změn v kódu budou tyto chyby v nejkratším možném čase odstraněny. V opačném případě se může stát, že ověřování kódu bude pravidelně selhávat kvůli nalezeným chybám, ale vývojáři začnou po čase tato upozornění ignorovat [54]. Jednou z vlastností CI je, že nemusí mít přesně nebo vůbec defi- nované cíle. To znamená, že kromě ověření kompilovatelnosti a prů- chodnosti kódu testy, nemusí být výstupem žádný artefakt, který by mohl být použit například k okamžité distribuci. Naopak, po skončení průběžné integrace následují manuální operace nad daným kódem jako je například v případě mobilního vývoje tvorba APK či IPA balíčků, tj. kompletace [54].

2.1.2 Průběžné doručení, průběžné nasazení Průběžné doručení2 je metodika vývoje software, která procesně nava- zuje na průběžnou integraci. Jejím účelem je ještě větší minimalizace zapojení lidské činnosti do procesu [54]. Výsledek každého provedení průběžného doručení je software, který lze kdykoli nasadit do produkčního prostředí. Změny provedené v kódu jsou ověřeny, zda jsou stále zkompilovatelné a prochází testy. Navíc zde následuje i samotná automatická kompletace projektu. Výsledek průběžného doručení se však do produkčního prostředí

1. Continuous integration. 2. Continuous delivery.

5 2. Procesy a automatizace nenasazuje automaticky, ale provádí se manuálně „na stisknutí tla- čítka“ [54]. Manuální nasazení je zde použito spíše z politických a strategic- kých rozhodnutí, než-li z technických důvodů [54]. Průběžné nasazení3 posouvá procesy z průběžného doručení ještě o úroveň dále. Zde se již provádí automaticky vše bez zásahu člověka, tedy i nasazení software do produkčního prostředí. V praxi to znamená, že každá provedená a nahraná změna v kódu do sdíleného repozitáře spustí kompilaci, veškeré automatické testy a kompletaci projektu. Výsledek kompletace se ihned nahrává do pro- dukčního prostředí, tzn. do produkce se nahrává nová verze aplikace každý den nebo nekolikrát denně [54]. Oba dva tyto termíny se zkráceně značí CD a i mezi odbornou společností dochází často k záměně významu obou metodik.

3. Continuous deployment.

6 3 Platforma Xamarin

Xamarin představuje ekosystém platforem poskytující nástroje pro tvorbu nativních multiplatformních aplikací určených pro iOS, An- droid, Windows či macOS. Obsahuje platformy Xamarin.iOS, Xama- rin.Android, Xamarin.Mac a Xamarin Test Cloud [57]. Xamarin pro tvorbu multiplatformních aplikací používá jeden pro- gramovací jazyk – C#. Díky tomu je možné jeden kód kompilovat pro všechny platformy najednou. Xamarin v tomto přístupu představuje unikátní řešení [57]. Aplikace vytvořené pomocí nástrojů Xamarin mohou přistupovat k nativním ovládacím prvkům uživatelského rozhraní a celé škále funkcí typických pro konkrétní cílovou platformu. Aplikace jsou kom- pilované a mohou využívat hardwarovou akceleraci. Oproti řešením, která kód pouze interpretují, jsou aplikace vytvořené na některé z platforem Xamarin mnohem výkonnější [58]. Nativní kompilace pro všechny platformy Xamarin dosahuje silně typovaným mapováním prvků a datových typů s téměř celým SDK, které leží pod platformou Xamarin [59]. Pro platformy Xamarin.iOS a Xamarin.Android platí, že jsou po- staveny na volně dostupné verzi .NET Framework označované Mono, která je dostupná ve všech běžných operačních systémech [59].

3.1 Mvvm, MvvmCross

Mvvm neboli model-view-view model je návrhový vzor, jehož cílem je jasně oddělit business logiku od logiky prezentační [60]. To rozdělení zajistí snadnější vývoj, testování a údržbu kódu aplikace a zvýší jeho znovupoužitelnost. Rozdělením a jasným vyme- zením obou částí aplikace zlepšuje efektivitu vývoje, který na obou částech může probíhat současně [60]. Na vyšší úrovni návrhu view ví o komponentě view model, ale ta neví o view. Podobně view model ví, že je pod ním model, ale ten neví, že view model existuje. Směrem nahoru, tj. od komponenty model až do view je komunikace zprostředkovaná pomocí notifikačních událostí. Díky tomuto přístupu view model zcela izoluje model od view a jeho vývoj je na něm zcela nezávislý [60].

7 3. Platforma Xamarin

Model obvykle obsahuje datový model společně s business a va- lidační logikou. View model definuje vlastnosti a příkazy, které jsou zpřístupňované přes view, který definuje vzhled a rozložení obrazovek v aplikaci [60]. MvvmCross představuje rámec postavený na Mvvm poskytující a zajišťující navigační systém v aplikaci, datové vazby, podporu speci- fických funkcí platforem či IoC a umožňující efektivně využívat výhod Mvvm [61]. Aplikace využívající MvvmCross jsou typicky složeny alespoň ze dvou částí. První z nich je jádro, které je tvořeno servisními třídami, komponentami view model a model a celou business logikou. Typicky se jedná o .NET Framework či .NET Standard projekt [61]. Prezentační vrstva nebo také UI je tvořen komponentou view a kódem, který je pro konkrétní platformu specifický. Při použití platformy Xamarin se bude jednat o projekty, které cílí na platformu Xamarin.iOS, Xamarin.Android či Xamarin.Mac, anebo .NET Fra- mework u Windows Presentation Foundation (dále jen WPF) [61].

8 4 Analýza

Před tím, než se začne vytvářet řešení pro konkrétní problém, je potřeba se s tímto problémem blíže seznámit a zjistit, jaký je aktuální stav. Teprve na základě zjištěných informací je možné začít problém řešit. Účelem této kapitoly je tudíž seznámit čtenáře jak s aktuálním stavem procesů ve firmě, které mají být zefektivněny, tak se všemi dalšími oblastmi, které je potřeba vzít v úvahu, aby bylo možné procesy automatizovat. V každé z těchto oblastí jsou představeny nástroje či přístupy, které se v daném kontextu používají, včetně zdůvodnění volby konkrét- ního řešení pro účely zefektivnění procesů. Některé z nich obsahují i informace o omezeních, se kterými je potřeba pocítat. Kapitola je zakončena shrnutím v podobě návrhu možného řešení.

4.1 Aktuálně nastavené procesy mobilního vývoje ve firmě

Firma A-WebSys začala s vývojem pro mobilní platformy v průběhu roku 2017. Na podzim téhož roku, v době zadání této diplomové práce, má firma za sebou již jednu experimentální aplikaci, jejímž účelem bylo především otestovat klíčové technologie, které by měly být použity pro produkční projekt. Ve stejné době se pomalu začíná pracovat na samotné produkční multiplatformní aplikaci, která je vyvíjená na platformě Xamarin s využitím rámce MvvmCross (viz sekce 3). Jedná se o aplikaci Anakin, která je určena pro finanční poradce ze společnosti Partners Financial Services, a.s. Jejím cílem je zpřehlednit a usnadnit komunikaci mezi poradci a klienty. Ač má firma za sebou již jednu aplikaci, stále má v této oblasti zatím málo zkušeností. Proto se do začátku vývoje produkčního projektu rozhodla využít základní poznatky z vývoje pro mobilní platformy a ty spojit s vývojovým modelem, který úspěšně využívá při vývoji internetových aplikací. Zároveň se pro mobilní vývoj u technologií využívaných i pro tvorbu webových aplikací, jako je například systém

9 4. Analýza pro správu verzí kódu, rozhodla firma přejít k modernějším alternati- vám. To znamená, že pro procesy mobilního vývoje aktuálně, tj. podzim 2017, platí následující: • Životní cyklus aplikace – Založen na agilních metodikách. Důvo- dem je schopnost rychle dodat záplatu pro chyby z produkčního prostředí či reagovat na změny požadavků ze strany klientů, příp. změny v trendech ve světě mobilních aplikací. Po vydání první oficiální verze aplikace by měl být jeden iterační cyklus dlouhý 14 dní, tj. zhruba každých 14 dní by měla být zveřejněna nová verze aplikace obsahující nové funkce a opravy nekri- tických chyb. Opravy kritických chyb zjištěných v produkční verzi aplikace by naopak měly být zveřejněny v nejkratším možném časovém úseku. Jeden iterační cyklus je typicky tvořen následujícími kroky: 1. stanovení cílů iterace, tj. určí se, co vše má být v rámci dané iterace hotovo, 2. návrh požadovaných funkcí, 3. implementace nových funkcí a oprav včetně vytvoření jednotkových testů, kontrola kódu, 4. testování, 5. nasazení. • Verzování kódu – Při vývoji internetových aplikací se pro správu verzí kódu dlouhé roky ve firmě používá systém Subversion. U mobilního vývoje se však rozhodlo k přechodu na systém Git ve spojení s nástrojem GitLab jako centrálním repozitářem. Ač má systém Git své nesporné výhody (viz srovnání těchto nástrojů v podsekci 4.2.1), práce s ním se v některých ohledech značně liší od použití SVN. Znalosti jednotlivých programátorů jsou velmi různorodé. Zároveň není cíleně nastavena konkrétní strategie větvení, která by práci s tímto systémem usnadnila, a de facto se používá centralizovaný pracovní postup (viz 4.2.2). Pro tým, tvořený šesti lidmi, není tato strategie sama o sobě zcela vhodná. Řízení bývá někdy matoucí, protože buď není stanoveno, kam by se vytvořená větev měla zpětně začlenit,

10 4. Analýza

nebo jsou některé větve otevřené moc dlouho a obsahují více nesouvisejících změn. To nakonec vede k pravidelným konflik- tům v souborech při slučování větví a celkově ke zpomalení sa- motného vývoje. Navíc provádět rychlé záplaty z produkčního prostředí bez nasazení neotestovaných částí kódu je v tomto případě skoro nemožné. • Implementace 1. Xamarin – Pro vývoj mobilních aplikací je používána archi- tektura Mvvm prostřednictvím rámce MvvmCross (viz sekce 3.1) společně s nativními platformami Xamarin.iOS a Xamarin.Android a jádrem postaveným na platformě .NET Framework verze 4.6.1. Bližší informace o platformě Xamarin je možné nalézt v kapitole 3. 2. Jednotkové testy – Jednotkové testy jsou vytvářeny přede- vším pro sdílený kód mezi platformami, tj. pro jádro aplikace. Za tímto účelem je používán nástroj MSTest. 3. Kontrola kódu – Pro tým vyvíjející obecně na platformě .NET není nastavena jednotná „štábní kultura“, což vede ke zpomalení při kontrole kódu po někom jiném, typicky v okamžiku dokončení úkolu před schválením změn do výchozí větve. V rámci tohoto kroku je potřeba vše prová- dět manuálně: stáhnout provedené změny, vyzkoušet, zda se posledními změnami něco nerozbilo, tj. v první řadě, jestli jde aplikace zkompilovat a prochází jednotkovými testy. Výsledek může ovlivnit i špatně nastavené prostředí nebo může dojít k nezáměrnému vynechání některého kroku. • Testování – Firma aktuálně ve svých řadách nemá nikoho přímo na pozici testera, nicméně do budoucna uvažuje o otevření této pozice. Testování aplikace tak zajišťují samotní programátoři. To může mít své výhody, neboť mohou nalezenou chybu rych- leji opravit, na druhou stranu nemusí provádět testování tak důkladně, právě z obav, že opět objeví nějakou chybu. • Nasazení – Provádí se zcela manuálně. To znamená v první řadě stáhnout na konkrétní stroj poslední revizi z repozitáře,

11 4. Analýza

ze které má být oficiální verze vytvořena. Následně se musí aplikace zkompilovat se správným nastavením a nejlépe pro jistotu ještě jednou pustit jednotkové testy. Nakonec je nutné vytvořit potřebné balíčky, IPA1 pro iOS a APK2 pro Android, které se následně nahrají na server, odkud si je mohou uživatelé stáhnout. Nabízí se zde dostatek prostoru k vytvoření nějaké chyby, která celý proces zastaví nebo zpomalí.

4.1.1 Klíčové ukazatele výkonnosti procesů

Klíčové ukazetele výkonnosti procesů (dále jen KPI3) představují ná- stroje či metodiky, kterými lze získat při správném nastavení důležité informace popisující efektivnost procesů konkrétní organizace, a tudíž poskytují přehled jejího stavu na cestě k dosažení stanoveného cíle [3]. V obecnosti mohou vhodně zvolené a použité metodiky vést ke zlepšení výkonnosti, minimalizaci chyb či zavedení inovativních způ- sobů v konkurenčním boji [3]. KPI lze aplikovat na cokoliv a pocházet mohou z různých zdrojů, které umožňují získat odpovědi na klíčové otázky. V praxi se však KPI nejčastěji používá měřením, kde můžeme výstupy snadno spočítat [3]. KPI lze rozdělit do dvou základních skupin. Strategické metodiky jsou určeny k vyhodnocení strategických cílů organizace, tj. zhodno- cení aktuálního stavu s budoucím očekávaným stavem, a staví spíše na pravidelném sledování pokroku a trendů na cestě ke stanovenému cíli. Účelem operativních nástrojů je na druhou stranu v reálném čase vyhodnocovat efektivitu procesů včetně výkonnosti systémů, strojů a lidí, kteří jsou jejich součástí [3]. Existuje velké množství KPI, ze kterých lze vybírat, případně je možné vytvořit si metodiky vlastní. Na začátku je tudíž potřeba stano- vit správné otázky, které vymezí klíčové oblasti, které je nutné měřit. Následně se určí zdroje a typ informací, které budou sloužit k získání odpovědi na položené otázky [3].

1. iOS App Package. 2. Android App Package. 3. Key Performance Indicators.

12 4. Analýza

4.1.2 Vyhodnocení výkonnosti procesů

Vzhledem k charakteru a zaměření práce se jako dobré ukazatele výkonnosti jeví například:

1. Frekvence integrace změn – Tato hodnota popisuje počet úspěšně schválených, tj. zkontrolovaných a následně i sloučených (větví), žádostí o integraci provedených změn za jeden den.

2. Výkonnost roury GitLab CI/CD – Hodnota vyjadřuje dobu tr- vání v sekundách jednoho průběhu roury v rámci průběžné integrace či průběžného nasazení.

3. Frekvence chybných nasazení aplikace do produkce – Hodnota vyja- dřuje počet nasazení aplikace do produkce, při kterých nastala chyba, tj. spadají sem i případy, u kterých nastala chyba při kompletaci aplikace, tj. tvorba APK či IPA balíčku za 75 dní.

Pro vyhodnocení výkonnosti procesů ve firmě budou použity ukazele Frekvence integrace změn a Frekvence chybných nasazení aplikace do produkce. Ukazel Výkonnost roury GitLab CI/CD nebude použit z dů- vodu chybějícího řešení průběžné integrace či průběžného nasazení před zahájením implementace praktické části, tzn. nejsou k dispozici data, která by mohla být použita. Jako zdroj k získání dat k vyhodnocení byl využit repozitář projektu Anakin z firemního serveru GitLab. Pro vyhodnocení výkonnosti procesů byla získána a zpracována data z období 75 po sobě jdoucích dní před integrací první části implementovaného řešení. Z dat vychází, že denně jsou integrovány zhruba 2 změny. Při nasazování aplikace do produkce se pak chyba objevila u každé druhé verze aplikace. Ve všech případech se jednalo o selhání z důvodu výskytu chyby již při kompletaci aplikace, nikoliv až po nahrání aplikace do produkčního prostředí. Chyba zpravidla byla způsobena buď tím, že kód nešlo zkompilovat, ať už kvůli špatně provedené integraci změn, anebo proto, že se již důkladně neprovedlo ověření kódu, anebo z důvodu zapomenutého zvednutí verze aplikace.

13 4. Analýza 4.2 Verzování kódu

Systémy pro správu verzí se dají obecně použít pro většinu typů sou- borů. Jejich hlavní přednosti jsou docenitelné především v situacích, kdy se stavy souborů mění velmi často nebo pravidelně [1]. Tyto systémy primárně umožňují sledovat a porovnávat změny provedené v digitálních informacích v čase a v případě nutnosti tyto změny jednoduše odvolat a obnovit data v některém z jejich dřívějších stavů. Zároveň zajišťují efektivnější spolupráci více lidí nad stejnými soubory pomocí snadnějšího sdílení informací [1][2]. Úprava dat a jejich bezpečné, tj. aby spolupracovníci byli chrá- něni od nežádoucího vzájemného přepisování provedených změn ve stejnou dobu, sdílení mezi spolupracovníky v obecnosti představují základní problémy, které musí každý verzovací nástroj řešit [1].

4.2.1 Git vs. Subversion Subversion (dále jen SVN) je tzv. centralizovaný systém pro správu verzí (CVCS4), který je aktuálně ve firmě používán pro většinu vyvíjených projektů. Pracovní model SVN je tvořen jedním repozitářem a n klienty, kteří s ním pracují. Repozitář představuje centrální úložiště na serveru, kde se ucho- vávají verzovaná data, a uživatelé na svých klientských strojích proti němu nahrávají a stahují provedené změny v souborech. Ty provádí lokálně v tzv. pracovní kopii repozitáře, tj. lokální kopii jedné konkrétní verze dat z centrálního úložiště, kterých může uživatel k jednomu repozitáři mít i více najednou [1]. Git je tzv. distribuovaný systém pro správu verzí (DVCS5). To znamená, že uživatelé narozdíl od SVN mají lokálně k dispozici úplný klon repozitáře, nikoli pouze jednu konkrétní verzi dat [2]. To s sebou přináší řadu výhod, ale i problémů (viz A.2). Při práci s nástrojem Git můžeme v rámci jednoho projektu použít jeden, více, tzn. že umožňuje snadno spolupracovat s více týmy na různých úrovních a aplikovat různé pracovní postupy pro konkrétní skupinu lidí v rámci jednoho projektu nebo žádný, tj. účastníci mezi

4. Centralized Version Control System [1]. 5. Zkratka z angl. Distributed Version Control System [2]. 14 4. Analýza

sebou přímo sdílí své lokální repozitáře, vzdálený repozitář a díky tomu uvažovat různé pracovní modely [2]. Od ostatních verzovacích systémů se Git liší především ve způ- sobu zpracování dat, kdy místo ukládání seznamů změn jednotlivých souborů ukládá data jako seznam tzv. snímků, které zachycují přesný stav souboru v čase. Pokud se soubor od poslední verze nezměnil, pak v rámci efektivity pouze uloží odkaz na dřívější snímek souboru [2]. Git oproti SVN označuje verze jiným způsobem. Protože v SVN se data vždy nahrávají do centrálního úložiště, je možné ke značení verzí použít přirozená čísla včetně nuly a při nahrání nové verze vždy zvýšit o jedničku. Pro Git by toto fungovat nemuselo, proto pro novou verzi dat Git vždy vypočítá tzv. SHA–1 otisk podle jejich aktuálního obsahu [1][2]. Ačkoli firma již několik let úspěšně používá nástroj SVN, dostal Git pro mobilní vývoj přednost. Důvodem této volby byly převládající výhody systému Git (viz A.2) oproti SVN (viz A.1) v klíčových bodech jako rychlost operací a výborná podpora nelineárního vývoje. Výho- dou je také skutečnost, že je možné v případě potřeby použít pro Git stejný pracovní model jako pro SVN, ale zároveň využívat přednosti distribuovaného systému. Rozhodování ovlivnila i skutečnost, že většina členů týmu mobil- ního vývoje se se systémem Git již alespoň krátce v minulosti setkala. Také u nových členů týmu se dá předpokládat, že je velká šance, že budou mít s nástrojem Git již nějakou dřívější zkušenost, protože DVCS dnes představují trend. I když ve firemním prostředí, kde je připojení k síti rychlé a stabilní, nemá možnost práce bez sítě takovou váhu, může se hodit například při práci z domu nebo na cestách. Naopak skutečnost, že má Git vyšší paměťové nároky, nemá při dnešních cenách permanentních pamětí vliv při rozhodování. Aby mohl být Git efektivně používán, je potřeba, vzhledem k jeho složitějšímu pracovnímu modelu, zvolit vhodný pracovní postup a pravidla jeho používání.

4.2.2 Strategie použití nástroje Git Volba vhodné sady doporučení pro práci se systémem Git předsta- vuje základ jeho efektivního používání. Cílem takové sady je přesně

15 4. Analýza

definovat, kdy provést které kroky a jak řešit situace, které mohou nastat. Ve výsledku mohou značně ovlivnit rychlost verzování dat díky odstranění přebytečné režie uvažování o další akci, která by měla následovat, minimalizuje výskyty nežádoucích stavů repozitáře a spolupráci členů týmu zjednodušší a posune na vyšší úroveň. Každý projekt nebo skupina souvisejících projektů má své vlastní požadavky a vlastnosti, které je vhodné zvážit při volbě množiny pravidel, protože jedna nejlepší univerzální strategie neexistuje. Mezi nejčastější nebo dobře známé pracovní postupy patří: Centralizovaný pracovní postup 6 Představuje velmi jednodnoduchou strategii, která odpovídá pracovnímu modelu v SVN. V repozitáři se pracuje s jedinou vývojovou větví, která se typicky nazývá master7, další větve nejsou potřeba. Vhodný pro malé týmy a týmy přecházející z SVN na Git. Výhodami jsou jednoduchost a přehledná lineární historie verzí. Nevýhodami jsou časté konflikty v provedených změnách dat, extrémně složitá paralelizace vývoje více funkcí projektu, master větev je v době vývoje nové funkce typicky nestabilní, na konceptuální úrovni není možné rozeznat stav projektu z pohledu nasazování do produkce, testování a ře- šení kritických chyb z produkčního nebo vývojového prostředí a tudíž nelze zavést automatizaci [2][5][7]. Pracovní postup s integračním manažerem V této strategii je jeden hlavní repozitář, který představuje celý vyvíjený projekt a o který se stará správce. Kromě správce nemůže do hlavního repozitáře nikdo zapisovat. Každý vývojář má vedle lokálního repozitáře také vlastní veřejný repozitář na straně serveru, do kterého může nahrávat data. Z repozitářů ostatních spolupracovníků může pouze číst. Pokud chce ně- který z přispěvatelů nahrát své změny do hlavního repozitáře, pak musí zaslat žádost správci, který si data může kdykoli stáhnout k sobě, otestovat a případně začlenit do projektu. Tento pracovní postup používá model větvení vycházející ze strategie GitFlow (viz 4.2.2). Je vhodný pro velké, organické

6. Také Lineární pracovní postup nebo Pracovní postup pouze s Master větví [6][7]. 7. V SVN se tato větev nazývá trunk [5].

16 4. Analýza

týmy a často se používá u open source projektů. Jeho výhodou je absolutní kontrola nad daty, které mohou být nahrány do hlavního projektu, a zároveň každý může pracovat bez přeru- šení svým vlastním tempem [2][12].

GitHub flow Jedná se o pracovní postup, který rozšiřuje lineární model (viz 4.2.2) definováním další větve označované jako feature větev. Pro každou novou funkcionalitu se vytvoří nová feature větev z větve master, která má přesný popisný název od funkce, která se v ní vyvíjí. V momentě, kdy je funkcionalita připravena, je skrze podání žádosti o sloučení, která je označována jako pull request nebo také merge request a představuje jednoduchý mechanismus pro kontrolu a diskuzi vyvíjených částí projektu, začleněna do větve master. Předpokládá se, že větev master představuje stabilní verzi projektu nasazenou v živém produkč- ním prostředí. Původně se nová verze do produkce nahrála při každém sloučení feature větve do větve master, avšak později se postup změnil do podoby, kdy se nová verze projektu nasa- zuje do produkce již z feature větve a v případě, že se objeví chyba v produkci, je možné verzi projektu vrátit na aktuální verzi ve větvi master, která je stabilní. Oproti lineárnímu modelu již lze paralelně vyvíjet funkce projektu a udržet hlavní větev po celou dobu stabilní, dále je možné částečně prová- dět automatické vydávání nových verzí a udržování záznamu o provedených změnách. Tato strategie je vhodná pro projekty, kde se očekává velmi časté nebo pravidelné vydávání nových verzí do produkce. Naopak se nehodí pro projekty, u kterých není možné mít pod kontrolou přesný okamžik vydání jako například u iOS aplikací, které musí projít kontrolou v App Store [5][6][7][8][9][13].

GitFlow Strategie byla poprvé publikována v roce 2010 Vincentem Driessenem a představovala první ucelenou a přesně defino- vanou sadu pravidel pro práci s nástrojem Git, která se oka- mžitě stala základní strategií. Vychází z pracovního postupu s feature větví, který rozšiřuje o další tři definované větve,

17 4. Analýza

resp. jejich role, a specifikuje, jak a kdy se jednotlivé větve vzájemně ovlivňují. V tomto modelu uvažujeme dvě hlavní větve master, která představuje stabilní verzi projektu nasazenou v živé produkci, a develop, která obsahuje změny připravené pro další verzi projektu, která bude v budoucnu nasazena do produkce. Tyto větve existují po celou dobu existence repozitáře. Zbylé tři větve, tzv. release, hotfix a feature, jsou pomocné, tzn. že v repozitáři existují pouze omezenou dobu, typicky dokud se nevyřeší problém, za jehož účelem vznikly. Větev release slouží k odladění a dokončení příprav nové verze projektu, která bude následně nasazena do produkce. Větev hotfix je určena k provedení rychlých záplat kritických chyb z produkč- ního prostředí a feature větev se používá pro vývoj nových funkcí projektu. Tento pracovní postup je poměrně robustní a je vhodný například pro velké projekty a projekty s napláno- vanými cykly vydávání. Hodí se pro projekty, které představují různé stahovatelné balíčky a knihovny, desktopové a mobilní aplikace. Výhodou této strategie je úplná automatizace procesů. To znamená, že v tomto modelu je možné na konceptuální úrovni přesně říci, jaký je stav projektu nebo odlišit záplatu kri- tické chyby z produkce od záplaty chyby ve vývoji. Umožňuje snadno verzovat projekt8, jednoduše udržovat seznam prove- dených změn nebo provádět automatické nasazení projektu do produkčního prostředí. V tomto modelu lze i v době příprav nové verze pokračovat ve vývoji dalších funkcí, které budou použity ve verzi následující. Jeho nevýhodou je, že obsahuje hodně pravidel a ve srovnání s ostatními strategiemi je poměrně složitý, což může vést k občasnému vynechání některého kroku. Potenciální nevýhodou se pak pro některé může jevit porušení konvence o výchozí vývojové větvi, která předpokládá, že je touto větví vždy větev master, v tomto modelu jí však je větev develop [7][10][11][13]. GitLab flow Představuje strategii, která rozšiřuje model GitHub flow a která nabízí dvě možnosti, jak ji použít. Základem je vývojová větev master a větev feature. Feature větev se vytváří pro každou novou

8. Například použití sémantického verzování [7]. 18 4. Analýza

Obrázek 4.1: Model strategie GitFlow [11].

funkci nebo za účelem oprav všech typů chyb a sloučena bývá zpravidla do větve master. Pokud bude vyvíjen software typu SaaS9, pak uvažujeme větve jako různá prostředí. Konkrétně vě- tev master obsahuje změny, které mohou být použity pro další verzi projektu. Dále máme dvě nové větve, tzv. předprodukční větev, ve které se provádí finální testování, nastavení verze, aktualizuje se seznam provedených změn atd., a produkční větev, která představuje produkční prostředí. Změny jdou vždy jed- ním směrem a to z větve master až do produkční větve. Pokud je vyvíjen projekt, který má být vypuštěn do světa, pak se uvažuje použití tzv. release větve, která představuje jednu konkrétní verzi projektu, což umožňuje vyvíjet více verzí projektu současně. GitLab flow řeší některé nedostatky GitHub flow jako například vývoj mobilních aplikací, a zároveň se snaží zjednodušit po- pulární model GitFlow se zachováním použitelnosti pro stejné případy. Nevýhodou je, že na konceptuální úrovni nelze rozlišit záplatu kritické chyby z produkce od záplaty chyby z vývoje či testování [13].

9. Zkratka z angl. Software as a Service.

19 4. Analýza

Vzhledem k aktuálně nastaveným procesům ve firmě (viz 4.1, se z výše zmíněných strategií ukazuje jako nejlepší volbou GitFlow, se kterým by neměl být problém uspokojit zmíněné požadavky. Naopak s centralizovaným pracovním postupem by nebylo možné vyvíjet více funkcí aplikace najednou a automatizace procesů by se také nedala zavést. Strategie využívající integračního manažera je vhodná pro velké projekty čítající velké počty vývojářů, ale pro malý tým je zbytečně složitá. Navíc jedním z předpokladů je, že pro jeden projekt se bude využívat jeden vzdálený repozitář, což s tímto modelem nelze splnit, a zároveň se u tohoto modelu GitFlow často používá v jednotlivých repozitářích. GitHub flow se hodí spíše pro projekty, které jsou zaměřeny na produkční prostředí a očekává se téměř každodenní nasazování no- vých verzí projektu. Dá se předpokládat, že nové verze budou ve firmě vydávány pravidelně, ale ne v rámci několika po sobě jdoucích dnů. Zároveň se zde řídí pravidlem, že ne každá produkční verze projektu bude potřebovat záplatovat nějakou kritickou chybu, což je například rozdíl oproti GitFlow, kde se toto předpokládá již na konceptuální úrovni a vede k lepšímu sledování stavu projektu a to je ve firmě požadováno. Nevýhodou je také možnost nasazení nové verze projektu do produkce kterýmkoli vývojářem z feature větve, což není žádoucí. GitLab flow představuje sice rozšíření GitHub flow modelu, ale z logického pohledu má velmi blízko právě ke GitFlow a jeví se jako výborná alternativa. Tento model se stejně jako GitHub flow hodí pro projekty, u kterých se očekává každodenní nasazování nových verzí softwaru a také nepředpokládá, že by každá produkční verze projektu mohla potřebovat záplatu nějaké kritické chyby. Proto naroz- díl od GitFlow není možné na konceptuální úrovni rozeznat opravu chyb z produkčního prostředí od opravy chyb z vývojového nebo testovacího prostředí, což je ale požadováno.

4.3 GitLab CI/CD

GitLab CI/CD představuje webovou aplikaci, která je určena ke kontrole a řízení samotného průběhu CI/CD. To znamená, že koordinuje

20 4. Analýza

jednotlivé operace a úkoly mezi aplikacemi označovanými jako runner (viz 4.3.1) a sbírá od nich výsledky, které dále zpracovává [14][16]. Nástroj GitLab do sebe plně integroval GitLab CI/CD od verze 8.0 a implicitně povoluje jeho použití pro každý nový projekt. Díky tomu je možné používat nástroj GitLab CI/CD skrze stejné uživatelské rozhraní jako samotný GitLab, provádět jeho prostřednictvím velké množství nastavení a mít celkový přehled informací o všech bězích CI/CD na jednom místě, a to i v reálném čase. Zároveň je možné jej s minimálním úsilím při nastavení používat s funkcemi aplikace GitLab jako je např. tzv. merge-request, přičemž jeho použití je intuitivní a přímočaré [16]. GitLab CI/CD je volně dostupný nástroj a může být použit s kte- roukoli aplikací určenou pro stejný účel jako GitLab [14]. Ač je stále nejběžněji používaným nástrojem pro automatizaci Jen- kins [25], byla aplikace GitLab CI/CD vybrána k používání především z těchto důvodů: • plná integrace v aplikaci GitLab používané ve firmě jako cent- rální repozitář – snadné a přímočaré použití, všechny informace a nastavení dostupné přehledně na jednom místě, • široká podpora cílových platforem, na kterých je možné nástroj použít, • je zcela volně dostupný, • výborná dokumentace, • velmi dobrá škálovatelnost a celkový výkon aplikace, • možnost paralelizace procesů CI/CD, • konfigurační soubor .gitlab-ci.yml (viz 4.3.1) je verzován spo- lečně s ostatním obsahem repozitáře, díky čemuž je GitLab CI/CD spouštěn vždy s konfigurací odpovídající stavu revize kdekoli napříč celou historii repozitáře.

4.3.1 Základní komponenty Základními pilíři aplikace GitLab CI/CD jsou konfigurační soubor gitlab-ci.yml, který definuje kdy, jak a co má být v rámci CI/CD prove-

21 4. Analýza

deno, a aplikace GitLab runner, která provádí jednotlivé úkoly načtené z konfiguračního souboru a s koordinátorem GitLab CI/CD komuni- kuje prostřednictvím API10 [14][16][17].

GitLab runner Představuje volně dostupnou aplikaci, která je zodpovědná za vykonání aktuálního úkolu, který čte z konfiguračního souboru, a výsledky reportuje zpět do GitLab CI/CD. Funguje na systé- mech Linux, OSX, FreeBSD a Windows a všude, kde je možné spustit Docker. Všude se instaluje jako služba, která běží na pozadí pod konkrétním uživatelským účtem a představuje tak de facto izolovaný stroj [14][17]. Podporuje použití terminálu Bash, Windows Batch či Windows PowerShell, Docker s nebo bez SSH, Parallels, virtuální stroje nebo prostá SSH prostředí. Runner a jeho nastavení lze měnit buď lokálně na stroji, kde je nainstalován, pomocí konfiguračního souboru config.toml, anebo skrze webové rozhraní nástroje GitLab [14]. Podle způ- sobu registrace, která se provádí po nainstalování aplikace, rozlišujeme následující typy: Sdílený runner Je vhodný pro provádění úkolů s podobnými požadavky napříč různými repozitáři. Díky tomu není nutné pro každý takový repozitář registrovat nový runner, ale je možné jej mezi nimi sdílet, pokud maji povoleno použití sdílených variant. Registrovat tento runner však může pouze uživatel s administrátorskými oprávněními k instanci aplikace GitLab, avšak v případě potřeby je možné jej změnit na specifický runner [17]. Specifický runner Je vhodný pro úkoly nebo celé projekty se specifickými požadavky k jejich provedení nebo pro případy zpracování velmi výpočtově náročných úkolů s požadavkem zajistit pro konkrétní projekt vždy alespoň jeden dostupný runner. Umožňují použití tzv. značek, díky kterým je možné rozli- šovat runner aplikace s konkrétními vlastnostmi a vytvářet

10. Zkratka pro Application Programming Interface

22 4. Analýza

z nich tak různé skupiny nebo jejich hierarchie. I tento runner může být použit pro více repozitářů současně. Rozdíl oproti sdílené variantě je, že v každém repozitáři musí být specifický runner manuálně povolen. Uživatel, který spravuje repozitář, tj. jedná se o vlastníka nebo správce (master), u kterého je přiřazen specifický runner, může tento runner přiřadit ke všem repozitářům, které také spravuje, pokud tento runner není výlučně určen jen pro konkrétní repozitář. Specifický runner může být použit jen pro explicitně definovaný projekt pomocí značek [17]. Skupinový runner Je vhodný pro skupinu projektů, pro kterou je požadováno použití jisté množiny runner aplikací. De facto se tudíž jedná o skupinu specifických runner aplikací. K vytvoření této varianty runner aplikace je zapotřebí mít administrá- torské oprávnění pro danou skupinu repozitářů v instanci GitLab [17]. YAML konfigurační soubor Tento soubor obsahuje definici všech úkolů, resp. všech kroků a operací, které se mají provést v rámci CI/CD s daným obsahem repozitáře. Nachází se v kořenovém adresáři repozitáře a společně s jeho obsahem je verzován. Díky tomu je konfigu- rační soubor aktuální vůči verzovanému stavu obsahu repo- zitáře [18] [19]. Základními prvky, které konfigurační soubor definuje, jsou: Úkol 11 Jedná se o základní jednotku GitLab CI/CD. V konfigurač- ním souboru yaml se zapisuje jako mapa nejvyšší úrovně, jejíž jméno musí být napříč celým souborem unikátní a ne- smí používat rezervované slovo. Rozlišují se dva typy úkolů a to povolený a zakázaný. Povolený úkol provádí aplikace runner a je viditelný v souhrnu informací o GitLab CI/CD v repozitáři GitLab. Zakázané úkoly začínají teč- kou a často se použivají jako šablony nebo pomocné pod- úkoly v rámci povolených úkolů. Každý úkol musí ob-

11. Angl. job.

23 4. Analýza

sahovat alespoň prvek script, v rámci kterého se definují příkazy, které se po vyzvednutí aplikací runner v jeho prostředí a v konkrétním kontextu provedou proti aktuální revizi obsahu repozitáře. Každý úkol se provádí v rámci konkrétní fáze GitLab CI/CD. Tu je možné specifikovat, případně se jako přednastavená použije fáze test. Kaž- dému úkolu je možné nastavit konkrétní vlastnosti jako například kdy se může provést, proměnné v příkazech, závislosti k ostaním úkolům ad. [18][19].

Fáze 12 Představuje fázi procesu GitLab CI/CD. Fáze se definují klíčovým slovem stages a na pořadí fází v této definici záleží, protože v tomto pořadí jsou vykonávány během CI/CD. Pokud není specifikována ani jedna vlastní fáze, pak se implicitně použijí fáze build, test a deploy. Úkoly v rámci jedné fáze se vůči sobě provádí s maximální pa- ralelizací, avšak úkoly z různých fází se vůči sobě pro- vádí sekvenčně. Přednastaveným chováním je, že až v mo- mentě, kdy všechny úkoly jedné fáze skončí úspěšně, se začnou provádět úkoly fáze následující. Toto nastavení je ale možné změnit. Zároveň platí, že každá fáze, pro kterou není definován žádný úkol, je při provádění CI/CD ignorována [18][19][20].

Roura 13 Roura reprezentuje kompletní množinu úkolů seskupených v jednotlivých fázích a zjednodušeně tudíž odpovídá jednomu běhu GitLab CI/CD. GitLab umožňuje roury přehledně pro- hlížet v reálném čase i zpět do minulosti. Ačkoli se v drtivé většině případů o rouře mluví jako o té jedné, ve skutečnosti se skládá ze tří podčástí – projektová roura, CI roura a nasazovací, resp. zaváděcí roura [21].

12. Angl. stage. 13. Angl. pipeline.

24 4. Analýza

4.3.2 Požadavky a omezení nástroje

Samotní tvůrci14 silně doporučují neinstalovat aplikaci GitLab runner na stejný stroj, na kterém je, anebo má být, nainstalována aplikace GitLab, a to z výkonnostních a bezpečnostních důvodů [22]. Z pohledu výkonnosti hraje roli, jaké a jak náročné operace bude GitLab runner muset provádět během testování obsahu repozitáře, a také jak je nakonfigurovaný. GitLab runner i samotný GitLab mohou vyžadovat netriviální množství paměti a v extrémním případě může dojít k úplnému zamrznutí aplikace GitLab, a tím i všech procesů s ní spojených [22]. Z bezpečnostního hlediska není bezpečné instalovat vše na jeden stroj. Především při použití běhového prostředí shell, tedy nativního prostředí fyzického stroje. Naopak za nejbezpečnější prostředí aplikace GitLab runner jsou považována Parallels, tedy úplná virtualizace, a Docker [22][23]. Tvůrci zároveň doporučují použít jeden stroj pro jednu instanci aplikace GitLab runner [22].

4.3.3 Požadavky a omezení na realizaci

Jedním z hlavních požadavků pro zavedení a použití GitLab CI/CD ve firmě je použití běhového prostředí shell pro aplikaci GitLab runner, a to i přesto, že je toto prostředí v obecnosti považováno za nejméně bezpečné, protože zpřístupňuje nativní prostředí fyzického stroje. Na druhou stranu toto prostředí nabízí ve srovnání s ostatními mnohem vyšší výkonnost při provádění GitLab CI/CD úkolů a konfigurace je snadnější. Dalším důvodem je omezení spojené s kompilací macOS a iOS aplikací (viz sekce 4.5). Z těchto důvodu se počítá s vyhrazením několika strojů s operač- ními systémy Windows15 a macOS16.

14. Open-core společnost GitLab Inc. [22]. 15. Pro Android a WPF aplikace 16. Pro iOS a macOS aplikace

25 4. Analýza 4.4 Kontrola kvality kódu

Jedním z klíčových bodů efektivnější práce vývojových týmů je kon- zistentní styl psaní kódu. K dosažení takového stavu je zapotřebí v každém týmu definovat soubor pravidel, kterými se musí každý člen týmu bez výjimky řídit a proti kterému je kód testován. Pro účely ověření kvality kódu proti předem definované množině pravidel existuje poměrně dost nástrojů17, které nám umožňují tento proces automatizovat. Roslynator2017 pro VS2017 Vytvořen Josefem Pihrtem a aktuálně provozován komunitou Roslyn, resp. komunitou kolem programu Visual Studio. Nástroj představuje kolekci více než pětiset pravidel určených k analýze a přeskládání kódu a jejich automatických oprav. Je postaven na .NET kompilační platformě Roslyn a neustále vyví- jen. Lze ho použít buď jako rozšíření do programu Visual Studio 2017, anebo nainstalovat prostřednictvím NuGet balíčků. Pro jednotlivé části nástroje existuje samostatný NuGet balíček, tj. není nutné instalovat všechny části, abychom jej mohli používat. U jednotlivých pravidel lze nastavit, zda mají být aktivní, a také jejich případnou akci při jejich porušení [26] [27]. FxCopAnalyzers Představuje nástroj s pravidly určenými spíše pro kontrolu kódu z pohledu bezpečnosti, výkonnosti a návrhových chyb, než-li z pohledu kontroly syntaxe kódu. Mnoho pravidel sou- časně nabízí i automatickou opravu. Je postaven na platformě Roslyn. Nahrazuje statický nástroj FxCop, který provádí kontrolu až nad sestaveným kódem, kdežto FxCopAnalyzers je spuštěn během kompilování kódu. Lze jej použít jako rozšíření v programu Visual Studio, anebo nainstalovat jako NuGet balí- ček do konkrétního projektu. Často se tento nástroj používá ve spojení s StyleCop Analyzers (viz podsekce 4.4.1) [28] [29]. GCop Nástroj vznikl v roce 2018 a představuje tak poměrně novou množinu pravidel pro syntaktickou analýzu. Je spravován

17. Tzv. syntaktické analyzátory 26 4. Analýza

a podporován s Geeks.Ltd. Pro jeho použití je potřeba v cílovém projektu nainstalovat NuGet balíček GCop.All.Common nebo GCop.All.Geeks, který pravidla zpřístupní. Pro správnou funkci některých pravidel, například pravidla pro kontrolu minimální úrovně viditelnosti členů třídy, je zapotřebí do programu Vi- sual Studio nainstalovat rozšíření GCop.Extra, které vyžaduje Visual Studio 2017 alespoň ve verzi 15.5.5. Umožňuje konkrétní pravidla nepoužívat pro specifikované třídy či metody. Nástroj je aktivně vyvíjen [30] [31].

4.4.1 StyleCop Analyzers Představuje nástroj vyvinut organizací DotNetAnalyzers, který je postaven na .NET kompilační platformě označované jako Roslyn [32]. Poskytuje sadu pravidel, která vychází z doporučení, konvencí a nejlepších praktik od společnosti Microsoft. Tato pravidla jsou roz- dělena do několika oblastí jako dokumentace, rozvržení, názvosloví, uspořádání, čitelnost, bílé znaky a ostatní. K některým pravidlům poskytuje i alternativy či automatické opravy při porušení daného pravidla [32]. Jednotlivá pravidla jsou definována v xml souboru s koncovkou .ruleset. Každému pravidlu je možné určit některou ze tří základních úrovní závažností porušení daného pravidla:

• Chyba – porušení takového pravidla způsobí, že nebude možné úspěšně zkompilovat kód, dokud nedojde k nápravě nežádou- cího stavu, všechna místa v kódu, kde je dané pravidlo poru- šeno, jsou vyznačena barevně jako chyba,

• Varování – porušení takového pravidla způsobí, že kód sice bude možné úspěšně zkompilovat, avšak s varováním, že něco není zcela v pořádku, všechna místa v kódu, kde je dané pravidlo porušeno, jsou vyznačena barevně jako varování,

• Žádná akce – takové pravidlo se při kontrole kódu nepoužije.

StyleCop Analyzers je možné nainstalovat jako NuGet balíček s po- užitím nástroje Visual Studio 2015 nebo Visual Studio 2017, případně jako rozšíření do Visual Studio 2017. Je možné jej bez problému použít

27 4. Analýza ve všech projektech postavených na platformách .NET Framework i .NET Standard. Do budoucna se počítá jen s podporou NuGet balíčků [32] [33]. V .NET Framework projektech je možné jednotlivá pravidla nasta- vovat v jednoduchém grafickém rozhraní, avšak v .NET Standard projektech je potřeba upravovat přímo xml soubory s koncovkou .ruleset. Výhodou je, že lze použít jeden sdílený soubor s pravidly napříč všemi projekty v rámci stejného řešení, anebo pro každý projekt definovat vlastní soubor s pravidly. Některá pravidla je navíc možné lehce pozměnit v souboru stylecop.json [32]. Jako nevýhoda se může projevit absence vyčlenění některých spe- cifických komponent v projektu, které nechceme podrobit kontrole kvality kódu. Tento nástroj byl nakonec oproti ostatním vybrán z následujících důvodů:

• Účel nástroje, tj. stará se jen o kontrolu stylu a konzistence psaní zdrojového kódu

• Jednoduché a přímočaré použití

• Funkční pro všechny .NET technologie

• Přináší ucelenou sadu pravidel vycházejících přímo z doporu- čení a konvencí společnosti Microsoft

4.5 Sestavení a jednotkové testy

K sestavení Android, macOS či iOS projektů postavených na platformě Xamarin je potřeba mít na stroji, kde má být zdrojový kód zkompilo- ván, dostupný nástroj msbuild. V operačním systému Windows se tento program používá skrze spustitelný soubor msbuild.exe, který je součástí buď instalačního ba- líčku prostředí Visual Studio, které však samo o sobě zabírá nezanedba- telné množství perzistentní paměti, anebo minimalistického balíčku o velikosti několika MB obsahující jen nezbytné nástroje k úspěšné kompilaci .NET projektů.

28 4. Analýza

V prostředí macOS, ve kterém se nepracuje se spustitelnými soubory mající příponu .exe, je nástroj msbuild zastoupen stejnojmenným skriptem, který lze bez omezení používat v termínálu. Současně by měl msbuild fungovat stejně na obou operačních systémech. Android aplikace postavené na platformě Xamarin lze bez omezení kompilovat v obou operačních systémech. Toto však neplatí pro macOS a iOS aplikace, které je nutné sestavit na zařízení od společnosti Apple s operačním systémem macOS. Důvodem tohoto omezení je nástroj Xcode, který je součástí operač- ního systému macOS a který obsahuje všechny potřebné technologie k navržení, sestavení a nahrání aplikace do App Store, odkud si ji mohou koncoví uživatelé stáhnout [24]. Apple však neprodává licenci svého operačního systému ostatním výrobcům, a zároveň v okamžiku, kdy tuto licenci uživatel získá a chce začít používat, je nucen souhlasit s podmínkami, že ji bude provozovat pouze na hardware od společnosti Apple. To znemožňuje efektivně použít virtualizaci pro systém macOS na zařízení od jiného výrobce, protože by tím došlo k porušení podmínek EULA18 společnosti Apple [24]. Mezi nejběžněji používané nástroje pro práci s jednotkovými testy při vývoji v jazyku C# patří MSTest a NUnit. Nástroj MSTest je součástí programu Visual Studio, kdežto NUnit se instaluje pomocí NuGet balíčků19. Použití obou nástrojů je velmi podobné a stejně tomu tak je i u jejich funkcí. Pro výběr vhodného ná- stroje se však jako zásadní z pohledu automatizace jeví bezproblémové používání z příkazového řádku či terminálu. Zatímco nástroj NUnit funguje bez znatelných problémů v pro- středí Windows i macOS, MSTest nelze použít vůbec, anebo jen se značnými problémy, v prostředí macOS.

4.6 Distribuce aplikace

Zveřejnění a zpřístupnění vytvořené aplikace koncovým uživatelům je nedílnou součástí životního cyklu vývoje každého úspěšného projektu.

18. End User License Agreement 19. NUnit, NUnit.ConsoleRunner, NUnit3TestAdapter

29 4. Analýza

Aby bylo možné vytvořenou Android či iOS aplikaci instalovat na mobilní zařízení, je potřeba z ní vytvořit příslušný podepsaný archív, tj. APK či IPA balíček. Jak lze takové balíčky vytvořit je uvedeno v podsekci 4.6.1. V podsekci 4.6.2 jsou představeny především programy a služby, které lze použít k distribuci aplikace pro testovací účely k živým testerům. Jak zpřístupnit aplikaci běžným uživatelům je uvedeno v podsekci 4.6.3, ve které je však věnováno více prostoru distribuci aplikací, které nejsou určeny pro širokou veřejnost, ale spíše pro vybranou skupinu specializovaných uživatelů.

4.6.1 Tvorba APK a IPA balíčků APK neboli Android application package představuje archív tvořený Android aplikací zkompilovanou s nastaveními určenými pro její nasazení a doplňujícími metadaty popisující další její vlastnosti. APK balíček může vytvořit kdokoli bez omezení. Nicméně před jeho vytvořením je nutné připravit aplikaci k nasazení. To například znamená nastavit aplikaci vhodnou ikonu, verzi, pokusit se zmenšit aplikaci na potřebné minimum, tj. vhodně nastavit nástroj Linker, který je použit pro optimalizaci a určení, které všechny soubory budou vy- tvořeny a zahrnuty ve výsledné zkompilované aplikaci, nebo nastavit podporované architektury procesorů. Po vytvoření APK balíčku je potřeba ho ještě digitálně podepsat příslušným certifikátem, aby bylo možné ověřit původ aplikace [40]. IPA neboli iOS application package, podobně jako APK balíček, před- stavuje speciální zip soubor, který je určený pro iOS aplikace. Aby bylo možné IPA balíčky vytvářet, je potřeba splnit několik podmínek: • Apple zařízení – Kvůli uzavřenosti ekosystému společnosti Ap- ple je potřeba IPA balíčky vytvářet na zařízeních Apple. Důvo- dem je především použití nástroje Xcode a digitální podepiso- vání balíčků certifikáty [41]. • Vývojářský účet Apple – Tento účet umožňuje vývojářům přiřadit aplikaci tzv. poskytovací profil20, který je aplikaci vydán spo-

20. Provisioning profile. 30 4. Analýza

lečností Apple a který obsahuje distribuční certifikát aplikace, seznam identifikátorů zařízení, na kterých může být aplikace použita a další. Tento účet je potřebný k získání potřebných certifikátů od společnosti Apple, která certifikáty spravuje sama. Apple vydané certifikáty propojí s požadovanými zařízeními, které jsou definované pomocí jejich identifikátorů. Pokud by aplikace nebo zařízení požadovaný certifikát neměly, pak by aplikaci nešlo nainstalovat. Tento účet je placený a nabízený ve dvou variantách. Standardní21 verze umožňuje vytvářet IPA ba- líčky pro testovací účely a nahrávat je do Apple App Store. Jeden standardní účet je možné propojit maximálně se 100 zařízeními. Podniková22 verze je určena především pro vývoj aplikací, která má být distribuována jen omezené množině uživatelů. S jedním účtem může být propojen neomezený počet zařízení, avšak není možné nahrávat aplikaci do Apple App Store. K distribuci je v tomto případě nutné použít jiný způsob, příp. mít zakoupené účty oba, aby mohla být aplikace distribuována do Apple App Store [41].

4.6.2 Distribuce k živým testerům K živým testerům se typicky distribuuje aplikace v tzv. beta verzi, která je určená pro testovací účely. S tímto typem verze je tedy potřeba příslušné APK či IPA balíčky vytvořit. U APK balíčků nejsou kladená žádná omezení, naopak u IPA balíčků je potřeba splnit potřebné podmínky i v případě, že se jedná o beta aplikaci distribuovanou k testerům (viz podsekce 4.6.1). K distribuci aplikace k živým testerům je možné použít celou řadu existujících nástrojů a služeb. Mezi ty, které lze použít k distribuci Android i iOS aplikací, a současně jejich volně dostupná verze nabízí zajímavé funkce, patří: Visual Studio App Center Představuje řešení od společnosti Microsoft, která v sobě integruje většinu funkcí známého nástroje HockeyApp, který byl ve- lice populární pro distribuci beta aplikací. Kromě Android a iOS

21. Apple Standard Developer Program. 22. Apple Enterprise Developer Program.

31 4. Analýza

aplikací je použitelný pro macOS, tvOS nebo Windows aplikace. Podporuje velké množství platforem jako Xamarin, Cordova, React Native ad. Umožňuje nahrávat aplikace buď skrze webové rozhraní nebo pomocí svého rozšiřitelného API, což umožňuje použít jej pro automatizaci. Pokud není žádoucí nahrávat již vytvořené zip soubory APK či IPA, je možné napojit tento nástroj přímo do repozitářů, kdy si například po každé revizi stáhne změny a sám provede kompilaci a vytvoření příslušného archívu určeného k distribuci. Takto přímo podporuje GitHub, BitBucket či Azure DevOps. Umožňuje vytvářet buď veřejné projekty, které jsou určené pro ostré verze aplikací a použité pro tzv. privátní distribuci aplikací (viz podsekce 4.6.3), anebo testovací tzv. beta projekty, kam se nahrává aplikace určená pro testery. Poskytuje širokou škálu funkcí pro práci a správu uživatelů a jejich skupin. Každé nahrané verzi aplikace lze přiřadit, kdo s ní může pracovat. Každý uživatel, který nemá oprávnění pro přístup k aplikaci, resp. ke konkrétnímu sesta- vení aplikace či verzi, si ji nebude moci úspěšně nainstalovat. Nabízí analytické funkce pro sběr dat například o využívání aplikace či zapojení testerů. Také poskytuje funkce pro sledo- vání a reportování případných chyb a selhání aplikace a jejich chytré organizování dle vlastností. Podporuje také například po- užití Appium či Xamarin.UITests pro automatické spouštění UI testů. Po nahrání aplikace do App Center se všem příslušným uživatelům zašle email s odkazem ke stažení. Pokud již uživatel aplikaci nahranou má a vyšla verze nová, pak App Center zajistí zprostředkování odkazu ke stažení pomocí notifikace. Navíc umožňuje použít i push notifikace. Je nabízen v několika verzích. Ve verzi zadarmo je možné použít všechny funkce, ale některé z nich jako je spouštění automatizovaných UI testů, sestavování aplikace přímo v App Center či push notifikace jsou omezené. Naopak již ve verzi zadarmo nabízí neomezený počet distribucí (u iOS omezeno použitým poskytovacím profilem) a uživatelů a neomezené používání ostatních funkcí [42].

Beta by Crashlytics Jedná se o testovací platformu použitelnou pro Android i iOS aplikace, která je součástí souboru nástrojů Fabric vlastněného

32 4. Analýza

společností Google. Má v sobě integrované funkce Crashly- tics, což je velmi známý nástroj pro své funkce určené ke sle- dování a reportování výskytů chyb a selhání aplikace. Navíc nabízí i analytické funkce například pro sledování aktivity testerů, stahování aplikace, úspěšnosti sestavení aplikace ad. Nabízí funkce pro správu skupin uživatelů, kdy skupinám lze přidělovat různá oprávnění a přístupy k různým sestavením a verzím aplikace. Po nahrání aplikace obdrží před první insta- lací email s odkazem, při aktualizaci obdrží notifikaci přímo z aplikace. Poskytuje distribuci neomezeného počtu aplikací neomezenému počtu uživatelů (opět u iOS ovlivňuje použitý poskytovací profil). Nabízí rozšiřitelné API, díky tomu je možné ho použít k automatizaci procesů. Je zcela zdarma, a to i pro produkční projekty [43].

4.6.3 Distribuce do produkčního prostředí

Pokud má být vytvořená aplikace veřejně zpřístupněna všem uživate- lům, potom je nejsnadnější způsob, jak nasadit aplikaci do produkč- ního prostředí, využít známé služby jako Google Play pro Android nebo Apple App Store pro iOS. Tyto služby poskytují výbornou podporu pro monitorování stavu aplikace či automatické aktualizace. Tím, že se jedná o velmi populární služby, získá vytvořená aplikace možný velký dosah mezi uživateli [45]. Pro využití služby Google Play je zapotřebí mít vytvořený vývo- jářský účet, který je placený, a skrze který se aplikace do Google Play nahrává. Aplikace musí být digitálně podepsaná certifikátem, jehož platnost je minimálně do 22. října 2033. Zároveň je potřeba splnit i požadavky na velikost aplikace, která může být maximálně 100 MB. Pokud je aplikace větší, je možné k APK balíčku přidat ještě 2 přídavné soubory, jejichž každého velikost může být až 2 GB. Vytvořenou aplikaci je možné nahrát například pomocí programu Visual Studio [44]. Aby bylo možné nahrát iOS aplikaci do App Store, je potřeba aplikaci vytvořit a distribuovat s využitím standardního poskytovacího profilu (viz podsekce 4.6.1). K nahrání je možné použít například program iTunes Connect.

33 4. Analýza

Aplikace však může být určena jen pro jistou množinu uživatelů, což je typické pro podnikovou sféru nebo pro aplikace cílící na úzkou specifickou skupinu lidí s jistým zaměřením či specializací. Jenutné tedy mít kontrolu nad tím, kdo si může danou aplikaci nainstalovat a používat. V takovém případě se jedná o tzv. privátní distribuci [45]. Android aplikace v tomto případě bývá nejčastěji distribuována pomocí emailu, který obsahuje buď odkaz ke stažení aplikace, anebo aplikaci samotnou. Aplikace může být ale vystavena ke stažení i na webové stránce [45]. K distribuci iOS aplikace je však zapotřebí používat správu mobil- ních zařízení (dále jen MDM23). To znamená, že je potřeba mít server, který je zodpovědný za uložení nasazených aplikací, a klienta nain- stalovaného na každém zařízení [46]. Navíc je potřeba mít aplikaci vytvořenou pomocí vývojářského účtu Apple určeného pro podniky, aby mohla být aplikace distribuována mimo App Store (viz podsekce 4.6.1). Pro privátní distribuci Android aplikací je možné využít placené služby v rámci Google Play, nicméně App Store nic podobného pro iOS nenabízí [46]. Způsob distribuce je zde velmi podobný jako u distribuce k živým testerům, také se jedná o vybranou skupinu uživatelů. Za tímto úče- lem se dá tedy uvažovat o nástroji Visual Studio App Center, který umožňuje vytvářet veřejné projekty, které jsou určeny pro aplikace nasazené do produkčního prostředí (viz 4.6.2).

4.7 Sběr dat od klientů

Sběr dat od klientů je důležitým prvkem ve vývoji mobilní aplikace. Každá informace, která může vést ke zlepšení aplikace, je důležitá. Sbírají se tak informace o chybách, reálném použití aplikace z pohledu obsahu, návrhu aplikace, rychlosti odezvy aplikace na ovládání uživatelem ad. Ke sběru dat je možné použít různé přístupy. Používá se například tzv. pasivního tlačítka pro zpětnou vazbu, které může být neustále viditelné, schované v navigačním menu nebo vyskočí v dialogu v konkrétních místech v aplikaci. Aktivací tohoto tlačítka může uživatel autorům předat informace prostřednictvím

23. Mobile Device Management. 34 4. Analýza

hlasování či dotazníků, může s autory komunikovat přímo přes chat či email nebo jim zašle snímek obrazovky z aplikace či začne snímat video [47]. Možné je použít i nástroje pro aktivní monitorování využití aplikace, jako je pohyb uživatelů v aplikaci a tvorba tzv. heat map, nejčastěji používané prvky či sledování výskytů chyb a pádů aplikace [47]. Například pro sběr informací o chybách je možné použít aplikace Crashlytics či Visual Studio App Center (viz podsekce 4.6.2) poté, co je jejich SDK integrováno do samotné aplikace. Většina nástrojů, které se zaměřují na sběr dat od klientů, je placená. Mnoho z nich sice nabízí neplacenou verzi, ale ta bývá buď velmi omezená, anebo slouží pouze jako dočasné demo. Příkladem mohou být nástroje Instabug [50] nebo HelpShift [49]. Než Microsoft získal HockeyApp, bylo možné použít tento ná- stroj zdarma pro sběr zpětné vazby od klientů. Avšak po integraci HockeyApp do Visual Studio App Center již tato funkce není dále podporována a je potřeba použít jiné řešení. Existuje však nástroj HelpStack, který představuje volně dostupný projekt pro sběr dat od klientů. Sám však přímo nepodporuje platformu Xamarin. Aby bylo možné je na platformě Xamarin použít, bylo by potřeba v začátku zajistit jeho integraci pro tuto platformu. HelpStack podporuje Android i iOS aplikace. Poskytuje funkce pro snadné zadávání zpětné vazby či hlášení chyb přímo ze spuštěné aplikace. Ke zpětné vazbě je možné přiložit i snímek obrazovky aplikace. Po odeslání reportu z mobilního zařízení dojde k vytvoření nového úkolu k vyřešení, tzn. podporuje tiketovací funkce. Mimo zasílání jednosměrné zpětné vazby poskytuje i funkce pro přímou komunikaci se zákaznickou podporu prostřednictvím chatu. Ke každé zaslané zprávě od uživatele automaticky připojuje informace o zařízení a aplikaci samotné. HelpStack je kompatibilní s HelpDesk programy jako Zendesk či Desk. Umožňuje zcela přizpůsobit vzhled svých obrazovek [48].

4.8 Návrh řešení

Základním pilířem celého řešení by měla být strategie GitFlow (viz 4.2.2). Její integrací do každodenních vývojových procesů by mělo dojít

35 4. Analýza především ke zjednodušení a zpřehlednění spolupráce ve vývojovém týmu, a tím k urychlení samotného vývoje. Použití tohoto modelu se projeví v řešeních dalších částí, a to především při nasazení a nastavení průběžné integrace, tj. nástroje GitLab CI/CD: • GitLab runner – Vzhledem k požadavkům a omezením nástroje GitLab runner (viz podsekce 4.3.2) a požadavkům na samotnou realizaci (viz podsekce 4.3.3) se jako zajimavé řešení jeví využít pro účely průběžné integrace stroje členů týmu zaměřeného na vývoj na platformě Xamarin. Toto řešení by mělo zajistit, že na všech příslušných strojích budou vždy k dispozici všechny potřebné nástroje pro práci s požadovanými projekty. Těchto počítačů je celkem 8, z nichž 7 používá operační systém Win- dows a jeden macOS. Na každém z těchto počítačů by měl být nainstalován GitLab runner s běhovým prostředím shell a s možností jedné či dvou jeho souběžně spuštěných instancí, které mají provádět operace v rámci průběžné integrace. • YAML soubor – Při definici tohoto souboru je důležité plně integrovat model GitFlow. To znamená, že jednou z podmínek při rozhodování, které z úkolů mají být provedeny a s jakými parametry, musí být název větve, ve které se provedené změny v kódu nachází. Provádění úkolů by se mělo spustit po každém nahrání změn do repozitáře GitLab, tj. po každé operaci git push. Vzniknou úkoly, které budou provádět kompilaci jednot- livých projektů v celém řešení daného repozitáře a úkoly pro spouštění jednotkových testů. Dle zaměření úkolů by tudíž měly vzniknout dvě fáze. Ve fázi build by měly být spuštěny všechny úkoly pro sestavení projektů včetně kontroly kvality kódu. Tato fáze by měla být následována fází test, ve které dojde ke spuštění a vyhodnocení jednotkových testů. Tato fáze by měla být spuštěna jen pokud budou všechny úkoly z fáze build úspěšné. Pro Git a nástroj GitLab CI/CD by měla být použita klonovací strategie, která zajistí, že budou operace prováděny nad soubory v požadovaném stavu, avšak bude pomalejší. Výsledkem úkolů kompilujících projekty budou bi- nární soubory a úkolů provádějící testování výsledky testů. Tyto výstupy budou stažitelné jako tzv. artefakty.

36 4. Analýza

K automatizaci procesu kompilace aplikace, resp. sestavení pro- jektů obecně, a ke spouštění jednotkových testů a jejich vyhodnocení je potřeba vytvořit skriptovací soubory. Pro každou operaci by měl vzniknout samostatný skript, aby bylo možné je jednoduše a libovolně používat. Skriptovací soubor určený ke kompilaci projektů bude pracovat s nástrojem msbuild (viz sekce 4.5). Vzhledem k použití modelu Git- Flow a jeho plné integraci do GitLab CI/CD bude potřeba, aby tento skript uměl ze vstupu načíst nejen název projektu, který má kompilovat, ale také informaci o konfiguraci a cílové platformě. Pro práci s jednotkovými testy vznikne skriptovací soubor, který bude pracovat s nástrojem nunit, a to i přesto, že byl doposud pro jed- notkové testy používán nástroj MSTest (viz sekce 4.5). Ze vstupu bude umět načíst projekt obsahující testy a také informaci o konfiguraci. Před zahájením samotné kompilace či vyhodnocování testů je po- třeba zajistit, že jsou k dispozici všechny NuGet balíčky, které projekty vyžadují ke správnému fungování. Protože se pracuje s platformou Xamarin a .NET Framework 4.6.1, vznikne skriptovací soubor, který bude mít úplnou kontrolu nad stažením potřebných balíčků. K tomuto účelu bude používat nástroj nuget, který se pro dané platformy hodí nejlépe. Ze vstupu bude umět získat název projektu pro který má balíčky stáhnout, včetně cesty ke zdroji, odkud mají být balíčky staženy. Kompilaci a testování iOS či macOS aplikace je potřeba provádět v prostředí operačního systému macOS (viz sekce 4.5). Z toho důvodu je potřeba vytvořit dávkové soubory pro Windows a shell soubory pro macOS. Ke kontrole kvality kódu bude použit nástroj StyleCop Analyzers (viz podsekce 4.4.1). Aby bylo možné mít výsledky testování kódu proti nastaveným pravidlům již v době kompilace kódu samotného, a tudíž byla kontrola kódu spuštěna v rámci procesu kompilace a měla na ní vliv, je potřeba do příslušných projektů tento nástroj integrovat včetně dané množiny pravidel. K tomu je zapotřebí do daných projektů nainstalovat NuGet balíček StyleCop.Analyzers verze 1.0.2. Následně vytvořit nebo použít existující sadu pravidel, kterou je potřeba do projektu přidat a nastavit jako aktivní množinu pravidel.

37 4. Analýza

4.8.1 Distribuce aplikace

Návrh uvedený v sekci 4.8 popisuje průběžnou integraci. Finální přípravy aplikace k distribuci a její samotné provedení již patří do oblasti průběžného nasazení, která vždy následuje až po průběžné integraci. Firma A-WebSys vytváří aplikaci, která je určena pouze pro některé uživatele. Z toho důvodu je potřeba provést privátní distribuci aplikace (viz podsekce 4.6.3). Pro tento účel se výborně hodí nástroj Visual Studio App Center (viz 4.6.2), který lze použít jak pro distribuci aplikace k živým teste- rům, tak do produkčního prostředí. Zároveň lze tento nástroj použít k monitorování a reportování aplikačních chyb a ke sbírání inforamcí o používání aplikace. Pro jeho použití stačí v požadovaných projektech aplikací nainstalovat NuGet balíčky Microsoft.AppCenter.Distribute, Microsoft.AppCenter.Analytics a Microsoft.AppCenter.Crashes. Distribuci aplikace je možné rozdělit do dvou kroků, a to vytvo- ření příslušného APK či IPA balíčku a jeho následné zpřistupnění požadovaným uživatelům. K vytvoření APK balíčku (viz podsekce 4.6.1) by bylo zapotřebí vytvořit dávkový soubor, který používá nástroj msbuild. Ten poskytuje funkce pro vytvoření APK balíčku i pro jeho digitální podepsání. K vytvoření IPA balíčku (viz podsekce 4.6.1) by bylo zapotřebí vytvořit skriptovací shell soubor, který používá nástroj Xcode, resp. jeho xcodebuild. K integraci balíčků do GitLab CI/CD je potřeba aktualizovat soubor YAML. Do něj by byla přidána nová fáze archive. V rámci této fáze by v souboru přibyly definice nových úkolů, které pracují se zmíněnými skriptovacími soubory. Musí být definovány úkoly, běžící na Windows pro tvorbu APK balíčků a běžící na macOS pro tvorbu IPA balíčků. Tyto úkoly by měly být spouštěny pouze v případě, že dojde k nahrání změn z větví release, hotfix a master. Ve větvi master by mělo dojít k označení, že se jedná o ostrou verzi, ve zbylých dvou větvích naopak k označení beta verze aplikace. Výstupem těchto úkolů budou artefakty obsahující vytvořené a podepsané balíčky, které se dají stáhnout. Pro samotné nahrání a zveřejnění aplikace jsou pak možná dvě řešení:

38 4. Analýza

1. Manuální – Nahrání aplikace, resp. vytvořených balíčků, do App Center by se provedlo přes webové rozhraní. Toto řešení umožňuje mít zcela pod kontrolou vyplnění seznamu změn, který je součástí nahrávacího procesu do App Center a slouží k informovanosti koncových uživatelů. Především ale umož- ňuje pro konkrétní sestavení aplikace určit, kdo k němu bude mít přístup, tj. kdo si jej bude moci stáhnout a nainstalovat.

2. Automatické – Tento případ je vhodný především pro případy, kdy je vyřešeno automatické sbírání informací o provedených změnách a koncová množina uživatelů je stále stejná. Pro fun- gování bude potřeba provést ještě tyto změny:

• Komunikace s App Center API – Bude potřeba vytvořit program, který bude umět komunikovat s REST API nástroje Visual Studio App Center. Skrze toto API budou zasílány balíčky přímo do konkrétního projektu vytvořeného v App Center. Při posílání aplikace se opět nastavuje, kdo s danou verzí může pracovat a seznam změn. Po nahhrání balíčku již App Center zajistí distribuci k uživatelům. • Skript – Jeho úkolem bude spustit vytvořený program a předat mu na vstupu vytvořené balíčky, které získá z artefaktů archivovacích úkolů průběžného nasazení. • YAML – Zde se buď přidá nová fáze s označením deploy a k ní příslušné úkoly, které pracují s vytvořeným skriptem. Tyto úkoly budou mít závislosti na úkolech z fáze archive, aby si mohly stáhnout jejich artefakty a použít je. Anebo dojde k přejmenování fáze archive na deploy a existující úkoly, které již slouží k vytváření příslušných balíčků, by byly rozšířeny o použití skriptu určeného k nahrávání balíčků do App Center.

39 5 Implementace

Při samotné realizaci praktické části bylo hlavním cílem postupovat dle vytvořeného návrhu řešení, které je nastíněno v sekci 4.8. Následující sekce obsahují kromě popisu dílčích částí vytvořeného finálního řešení také informace o zajimavých překážkách, které bylo nutné při implementaci vyřešit. Přesto, že se v analýze vývojových procesů na platformě Xamarin ve firmě A-WebSys rozebírá produkční projekt Anakin, popisuje podsekce 5.3.2 řešení použité u projektu WebViewBridge, a to z důvodu, že pro tento projekt, který je také vyvíjen na platformě Xamarin, se podařilo vytvořit řešení pro průběžné nasazení. WebViewBridge je knihovna určena k zajištění komunikačního kanálu mezi uživatelským rozhraním psaným v jazyce Javascript a logikou běžící na pozadí psanou v jazyce C#, která používá komponenty specifické pro konkrétní platformy WPF, Android, iOS a macOS. Knihovna je tvořena několika projekty, z nichž některé používají roz- hraní .NET Standard 2.0 a jiné jsou specifické pro konkrétní prostředí a ty jsou postavené na platformě Xamarin. Závěr kapitoly patří zhodnocení výstupu práce z pohledu úspěš- nosti nasazení vytvořeného řešení do firemních procesů a celkového dopadu na jejich efektivnost.

5.1 Nastavená pravidla pro kontrolu kvality kódu

Pro kontrolu kvality kódu byl použit nástroj StyleCop Analyzers (viz podsekce 4.4.1) ve verzi 1.0.2., který obsahuje celkem 169 pravidel, z nichž některá představují alternativní řešení pro jiné pravidlo. V této verzi má analyzátor po nainstalování u všech pravidel nastavenou akci na varování. Nastavení pravidel bylo celkově provedeno ve dvou krocích. V prv- ním kroku se pravidla rozřadila mezi kritická, normální a nedůležitá dle obecně zavedených konvencí a nejlepších praktik používaných při vývoji v programovacím jazyku C# a na platformě .NET. Poté následovalo zapojení členů týmu, u kterého se předpokládalo zavedení kontroly kvality kódu s těmito pravidly. Komunikace s členy

40 5. Implementace

týmu byla provedena s cílem optimalizovat sadu pravidel za účelem snadnějšího nasazení a použití. Výslednou množinu pravidel, kterou lze najít v přílohách (viz tabulka A.3), tvoří 78 s akcí chyba, 72 s akcí varování a zbylých 19 pravidel není při kontrole kvality kódu použito.

5.2 Skriptovací soubory

Při implementaci skriptovacích souborů dle návrhu uvedeného v sekci 4.8 bylo cílem každý skript vytvořit s následujícími vlastnostmi: Znovupoužitelnost – Skript by mělo být možné použít na více stro- jích vyhrazených pro průběžnou integraci mající požadovaný operační systém Windows nebo macOS, a to bez nutnosti pro- vádět v tomto souboru jakékoli změny, popř. s nutností provést změny pouze minimální. Takový skript by měl tudíž podporovat načítání potřebných parametrů k vykonání specifické operace zvenčí a ty správně používat.

Jednoduchost – Skriptovací soubor by měl umožnit přednastavení vstupních parametrů. Důvodem je, že skript může podporovat velké množství parametrů zadávaných zvenčí. Hodnoty mnoha z těchto parametrů však mohou být při jednotlivých spouště- ních skriptu často stejné a uživatel by v těchto případech musel na vstupu zadávat tyto hodnoty neustále dokola. Současně by měl takový skript podporovat nápovědu pro jeho samotné použití.

Čitelnost – Obsah skriptovacího souboru by měl následovat jednot- nou strukturu pro oba operační systémy Windows a macOS, která by měla usnadnit a urychlit orientaci v souboru. Jednotná struktura, použitá při implementaci každého skriptova- cího souboru, je tvořena následujícími částmi: a. Inicializace proměnných

b. Definice pomocných funkcí včetně nápovědy

c. Zpracování vstupních parametrů

41 5. Implementace d. Použití přednastavených hodnot u všech parametrů nezada- ných na vstupu e. Provedení příslušných operací

Vytvořeny byly celkem čtyři dávkové soubory určené pro operační systém Windows a čtyři shell soubory pro operační systém macOS: win10_nugets_restore.bat, macOS_nugets_restore.sh Tyto soubory obsahují příkazy, které pro požadovaný C#/.NET řešení stáhnou všechny nainstalované NuGet balíčky. Při jejich spuštění lze na vstupu nastavit cestu k adresáři, kam se mají NuGet balíčky stáhnout či odkud mají být balíčky staženy. Ze vstupních parametrů je povinný pouze parametr -solution. Všechny ostatní jsou volitelné, tj. pro každý parametr, který není na vstupu zadán, se použije přednastavená hodnota. Celý seznam vstupních parametrů je k nalezení v přílohách A.3.1. K vykonání této operace používají nástroj msbuild. Důvody, které vedly k rozhodnutí a volbě tohoto nástroje pro tento účel, je možné nalézt v sekci 5.4. Ukázku ze souboru win10_nugets_restore.bat s příkazy, které provádí obnovení balíčků, je možné najít v 5.1. Verze téhož bloku ze souboru macOS_nugets_restore.sh se nachází v přílo- hách v ukázce A.1

1 rem restore NuGet packages for the solution file 2 call :print_message "Starting NuGet packages restore for solution '%solutionFile% '..." 3 "%\textit{msbuild}%" /t:restore "%solutionFile%" /maxcpucount /p:RestorePackagesPath=" %packagesDirectory%" /p:RestoreSources=" %source%" /p:Configuration="%configuration%" /property:Platform="%platform%" /p:RestoreNoCache=%noCache% /p:RestoreDisableParallel=%disableParallel% /verbosity:%verbosity% 4 5 if /i "%errorlevel%" NEQ "0" (

42 5. Implementace

6 call :print_message "ERROR: NuGet packages restore failure." 7 endlocal 8 exit /b %errorlevel% 9 ) else ( 10 call :print_message "NuGet packages restored successfully." 11 ) 12 13 rem all processes succeeded- end with success 14 endlocal 15 exit /b 0 Listing 5.1: Příkazy pro obnovení NuGet balíčků a vyhodnocení operace v souboru win10_nugets_restore.bat. win10_build.bat, macOS_build.sh Skriptovací soubory jsou určeny ke kompilaci konkrétního C#/.NET projektu dle nastavených parametrů. Při spuštění těchto skriptů je možné na vstupu například kam se mají zapisovat logovací informace, platformu nebo konfiguraci. Na vstupu musí být vždy uveden projekt, a to buď zadáním jeho názvu s koncovkou, anebo bez, anebo celou cestu, která může být relativní nebo absolutní. Celý seznam vstupních parametrů pro tyto skripty se nachází v přílohách A.3.1. Pokud je obnovení NuGet balíčků pro daný projekt vyžado- váno, provede se před zahájením kompilace. K obnovení NuGet balíčků se použije skript win10_nugets_restore.bat nebo ma- cOS_nugets_restore.sh podle operačního systému, na kterém je kompilovací skript spuštěn. Kompilace se následně spustí jen v případě, že se podařilo všechny potřebné NuGet balíčky úspěšně stáhnout. V ukázce 5.2 lze najít příkazy, které ze skriptovacího souboru win10_build.bat volají skript win10_nugets_restore.bat pro obno- vení NuGet balíčků. Obnovení NuGet balíčků pro daný projekt se provádí před zahájením samotné kompilace, pro kterou se používá nástroj msbuild (viz sekce 4.5) a jejíž ukázku lze najít v 5.3. Verze týž bloků ze souboru macOS_build.sh se nachází v přílohách v ukázkách A.2 a A.3.

43 5. Implementace

1 if /i "%dorestore%" EQU "true" ( 2 rem restore NuGet packages for the project and route the output to the NuGet packages restore log file 3 call :get_file_from %solutionFileAbsolute% solutionFile 4 call :get_folder_from %solutionFolderAbsolute% solutionFolder 5 call :get_file_from %nugetRestoreLogFileAbsolute% nugetRestoreLogFile 6 call :print_message "Restoring NuGet packages for solution '!solutionFile!' - logger output redirected to file '!solutionFolder!\! nugetRestoreLogFile!'" 7 call "!nugetRestoreScriptAbsolute!" -solution "%solutionFileAbsolute%" -platform " %platform%" > "%nugetRestoreLogFileAbsolute%" 8 if /i "%errorlevel%" NEQ "0" ( 9 call :print_message "ERROR: Restoring NuGet packages for solution '!solutionFile!' failed --BUILDABORTED." 10 endlocal 11 exit /b %errorlevel% 12 ) else ( 13 call :print_message "NuGet packages restored for solution '!solutionFile!' successfully." 14 ) 15 ) Listing 5.2: Obnovení NuGet balíčků v souboru win10_build.bat.

1 call :print_message "Starting build of project ' %projectFile% ' in configuration ' %configuration% ' for platform '%platform% ' ..." 2 "%\textit{msbuild}%" "%projectFileAbsolute%" /consoleloggerparameters:ErrorsOnly /maxcpucount /t:Clean;Build /p:Configuration= %configuration% /p:RestorePackages=False /p:BuildProjectReferences=%buildReferences%

44 5. Implementace

/property:Platform="%platform%" /verbosity:%verbosity% 3 if /i "%errorlevel%" NEQ "0" ( 4 call :print_message "ERROR: Building project ' %projectFile% ' failed ." 5 endlocal 6 exit /b %errorlevel% 7 ) else ( 8 call :print_message "Project '%projectFile% ' built successfully." 9 ) 10 11 rem all processes succeeded- end with success 12 endlocal 13 exit /b 0 Listing 5.3: Příkazy pro sestavení požadovaného projektu v souboru win10_build.bat.

win10_nuget_pack.bat, macOS_nuget_pack.sh Skripty obsahují příkazy k vytvoření NuGet balíčků z poža- dovaných C#/.NET projektů a jejich následnému nahrání do cílové lokace. Na vstupu je možné nastavit například cestu k místu, kam mají být vytvořené Nuget balíčky nahrány, nebo autorizační token, který se použije při přístupu k danému místu. Vždy musí být na vstupu zadán alespoň jeden projekt. Zadat je možné ale celý seznam projektů. Přehled vstupních parametrů pro tyto skripty jsou k nalezení v přílohách A.3.1. K vytváření nových NuGet balíčků ze specifikovaných projektů používají tyto skripty nástroj msbuild, ale k samotnému nahrání vytvořených balíčků do požadované destinace používají nástroj nuget. Bližší informace popisující důvody volby těchto nástrojů pro tyto operace lze nalézt v sekci 5.4. Na začátku vytváření se vždy provede obnovení NuGet balíčků pro všechny projekty, ze kterých mají být vytvořeny NuGet balíčky. Tento krok je potřebný, aby nástroj msbuild byl schopen vyřešit všechny závislosti projektu, když shromažďuje všechna metadata, která následně použije při tvorbě NuGet balíčku. Po úspěšném obnovení NuGet balíčků se pokračuje vytvářením

45 5. Implementace

NuGet balíčků z projektů. Ukázku s příkazy pro vytvoření Nu- Get balíčků lze najít v 5.4 a pro následné nahrání vytvořených NuGet balíčků je k dispozici ukázka 5.5.

V přílohách se nachází ukázky stejných bloků příkazů, tj. A.4 pro vytvoření NuGet balíčků a A.5 pro jejich zvěřejnění, urče- ných pro macOS.

1 rem for each project do 1. get the absolute path ; 2. check the project exists; 3. pack project 2 set /a "lastProjectIndex=%numberOfProjects% - 1" 3 set "ciRepoFolder=%cd%" 4 for /l %%n in (0,1,%lastProjectIndex%) do ( 5 rem get the absolute path to the project file 6 call :resolve_project_file !projects[%%n]! projectAbsolute projectFile 7 if /i "!errorlevel!" NEQ "0" ( 8 call :print_message "Project '!projects[%%n ]!' is not present in the repository -- NUGET PACKINGSKIPPED." 9 ) else ( 10 call :print_message "Starting NuGet package creation from '!projectFile!' in configuration '%configuration% ' ..." 11 "%\textit{msbuild}%" /t:pack "! projectAbsolute!" /p:NoBuild=true /p:NoRestore=true /p:PackageOutputPath=" %ciRepoFolder%\CreatedNuGets" /p:VersionSuffix=%suffix% /p:Configuration=" %configuration%" /verbosity:%verbosity% 12 if /i "!errorlevel!" NEQ "0" ( 13 call :print_message "ERROR: NuGet package creation from project '!projectFile!' failed . " 14 ) else ( 15 call :print_message "NuGet package from project '!projectFile!' created successfully. " 16 ) 17 ) 18 )

46 5. Implementace

Listing 5.4: Vytvoření NuGet balíčků ze specifikovaných projektů v souboru win10_nuget_pack.bat.

1 rem publish all created NuGet packages to the server(NuGet packages repository) 2 for /f "usebackq tokens=*" %%n in (` dir /b /s CreatedNuGets\*.nupkg `) do ( 3 call :print_message "Starting publishing of NuGet package '%%n ' to source '%source% '..." 4 "%nuget%" push "%%n" -apikey "%apiKey%" -source "%source%" 5 if /i "!errorlevel!" NEQ "0" ( 6 call :print_message "ERROR: Publishing of NuGet package '%%n ' failed ." 7 endlocal 8 exit /b ! errorlevel ! 9 ) else ( 10 call :print_message "NuGet package '%%n ' published successfully." 11 ) 12 ) 13 14 rem all processes succeeded- end with success 15 endlocal 16 exit /b 0 Listing 5.5: Nahrání vytvořených NuGet balíčků do cílové destinace v souboru win10_nuget_pack.bat.

win10_nunit_unit_test.bat, macOS_nunit_unit_test.sh Skriptovací soubory jsou určeny ke spouštění všech dostupných jednotkových testů existujících v požadovaném projektu. Na vstupu je potřeba vždy zadat název nebo cestu k projektu, který obsahuje jednotkové testy. Předpokládá se, že je tento projekt již zkompilovaný. Celý seznam parametrů, které lze na vstupu zadat se nachází v přílohách A.3.1. Pro spuštění, vyhodnocení a tvorbu výstupních informací jed- notlivých jednotkových testů používají skripty nástroj NUnit

47 5. Implementace

(viz sekce 4.5). Zároveň je při spuštění těchto skriptovacích souborů zapotřebí, aby projekt, který obsahuje jednotkové testy, které mají být spuštěny, byl již zkompilovaný. Kromě výpisu in- formací v průběhu provádění jednotlivých testů na standardní výstup, jsou výsledky testů uloženy do souboru s názvem TestResults_yyyy-MM-dd_hh-mm.xml, tj. za názvem TestResults je uvedeno datum a čas spuštění testů, který se nachází v adre- sáři určeném parametrem -testresults. V ukázce 5.6 jsou k vidění příkazy pro spuštění a vyhodnocení jednotkových testů s použitím nástroje nunit, přičemž v přílo- hách v ukázce A.6 jsou uvedeny tytéž příkazy pro platformu macOS.

1 rem get the actual system date in format yyyy-MM-dd 2 for /f "tokens=1-3 delims=/./ " %%a in (' date /t ') do ( set mydate=%%c-%%a-%%b) 3 rem get the actual system time in format hh-mm 4 for /f "tokens=1-2 delims=/:" %%a in (' time /t ') do ( set mytime=%%a-%%b) 5 6 rem run unit tests with nunit console runner and store results into given folder 7 "%nunit%" "%projectDLLAbsolute%" /work:" %testResultsDirectory%" /labels:All /result:TestResults_%mydate%_%mytime%.xml /out=TestsOutput.txt /config:%configuration% 8 if /i "%errorlevel%" NEQ "0" ( 9 call :print_message "ERROR: Processing unit tests from '%projectFile% ' failed ." 10 exit /b %errorlevel% 11 ) else ( 12 call :print_message "Unit tests processed successfully." 13 ) 14 15 endlocal 16 exit /b 0 Listing 5.6: Spuštění jednotkových testů v souboru win10_nunit_unit_test.bat.

48 5. Implementace

U všech výše zmíněných skriptovacích souborů je možné vyvolat nápovědu zadáním vstupního parametru -help. Nápověda obsahuje informace o vstupních parametrech jednotlivých souborů, tj. jejich popis včetně informace o přednastavené hodnotě v případě volitelných parametrů. Pro každý skript také platí, že v okamžiku zadání neplatného parametru na vstupu končí s chybou a výpisem na standardní výstup, který ze zadaných parametrů chybu způsobil.

5.3 Nastavení GitLab CI/CD

V této sekci jsou popsána jednotlivá nastavení důležitých částí nástroje GitLab CI/CD. To znamená, že je zde popsána struktura konečného řešení sítě počítačů, na kterých jsou zprovozněny aplikace GitLab runner (viz 4.3.1), včetně jejich nastavení. Dále je zde popsán vytvořený konfigurační soubor YAML (viz 4.3.1) použitý u firemního projektu WebViewBridge (viz úvod kapitoly 5), který definuje operace a úkoly, které ve výsledku představují řešení pro průběžné nasazení software.

5.3.1 GitLab runner

Původní řešení vycházející z předpokladů uvedených v návrhu, jež se nachází v sekci 4.8, se ukázalo jako nevhodné1 a bylo nutné jej nahradit jiným. Schéma sítě, které je ve firmě aktuálně nasazeno a které se používá již několik měsíců, je tvořeno dvěma stroji, jež jsou výhradně určeny pro účely průběžné integrace. Prvním z nich je virtuální stroj s operačním systémem Windows 10, který běží nepřetržitě na velmi výkonném serveru. GitLab runner je nainstalován s běhovým prostředím shell a tudíž pracuje přímo v prostředí virtuálního stroje. Ten se mimo účely prů- běžné integrace na nic jiného nepoužívá, proto zde není toto nastavení kritické jako v předešlém případě.

1. Bližší informace se nachází v podsekci 5.4.1

49 5. Implementace

Současně může na tomto počítači běžet až 8 agentů v jeden oka- mžik, tj. umožňuje paralelně provádět až 8 úkolů určených pro ope- rační systém Windows. Druhý stroj je Mac mini Late 2012 s operačním systémem macOS Mojave ve verzi 10.14 v nejvýkonějším sestavení. Je to tentýž stroj, který byl pro průběžnou integraci používán od začátku, ale nyní se na něm již nevyvíjí a je vyhrazen pouze pro operace průběžné integrace. Nastavení nástroje GitLab runner je velmi podobné jako u prvního stroje, avšak zde mohou být v jednom okamžiku spuštěni pouze dva agenti vykonávající úkoly průběžné integrace. Toto nastavení se ukázalo jako ideální z pohledu poměru rozdělení úkolů provádě- ných v prostředí Windows a macOS a z pohledu efektivního vytížení hardwarových zdrojů počítače Mac mini (viz ukázka 5.7).

1 concurrent = 2 2 check_interval = 0 3 4 [[runners]] 5 name = "" 6 url = "" 7 token = "" 8 executor = "shell" 9 [runners.cache] Listing 5.7: Konfigurační soubor config.toml nástroje GitLab runner použitý na počítači Mac mini Late 2012.

5.3.2 YAML soubor Konfigurační soubor YAML pro GitLab CI/CD se definuje vždypro každý projekt spravovaný v rámci programu GitLab zvlášť. Z toho důvodu bude v této sekci popsán jeden z několika vytvořených YAML souborů., který se používá pro interní firemní projekt s označením WebViewBridge. Souborem YAML byly nástroji GitLab CI/CD pro tento projekt nastaveny následující vlastnosti:

• Zpracování úkolů nástrojem GitLab CI/CD se spustí při kaž- dém nahrání změn do centrálního repozitáře na serveru GitLab,

50 5. Implementace

tj. pro každou úspěšnou operaci git push, která přináší nějaké změny. Například, jsou-li lokálně vytvořeny revize1 a revize2 a až následně jsou změny nahrány na server GitLab, potom se GitLab CI/CD spustí jen jednou pro repozitář ve stavu revize2. Pokud by však došlo k vytvoření revize1 a jejímu nahrání na server GitLab a teprve následně by došlo k vytvoření revize2 a je- jímu nahrání na server GitLab, pak by v takovém případě došlo ke spuštění průběžné integrace dvakrát. Jednou pro projekt ve stavu revize1 a podruhé ve stavu revize2. • Používá se klonovací Git strategie, která zajistí, že jsou úkoly prováděny nad daty ve stavu přesně odpovídajícímu tomu na serveru GitLab. To znamená, že předtím, než GitLab runner začne provádět konkrétní úkol, naklonuje si vždy celý repozitář k sobě ve stavu odpovídajícímu poslední nahrané revizi operací git push, která průběžnou integraci spustila. Klonování zajistí kompletní přepsání případně existujících dat na stroji, čímž je odstraněno riziko ovlivňování výsledku operací například dynamicky generovanými soubory. Například, jsou-li nadefino- vány k provedení 2 úkoly, které provádí stejná instance GitLab runner, pak i v takovém případě se před zahájením zpracování každého úkolu na začátku vždy naklonuje repozitář v daném stavu. V tomto případě by tudíž došlo k naklonování dvakrát. • Každá fáze, nejedná-li se o fázi první, se spustí pouze po úspěš- ném dokončení fáze předchozí. • Model GitFlow2 je plně integrován v definicích všech úkolů v souboru YAML. To ve výsledku znamená, že zdrojová větev, resp. její název, ze které byly změny nahrány, určuje, které z definovaných úkolů, a tudíž i všechny fáze, mají být provedeny včetně všech dílčích nastavení jako jsou například vstupní parametry předávané skriptům (viz příklad odkaz). Struktura YAML souboru je následující: Definice proměnných a nastavení vlastností nástroje GitLab CI/CD

2. Model je lehce upraven, přidává ještě navíc větve prerelease, které spadají do oblasti mezi větví develop a release.

51 5. Implementace

Vlastní proměnné jsou definované za účelem lepší čitelnosti kódu. Většina proměnných obsahuje buď název projektu, anebo cestu ke zdroji používaném při nějaké specifické operaci. V této části je nastavena i klonovací Git strategie (viz ukázka 5.8).

1 variables: 2 3 #======CI and Git ======4 GIT_STRATEGY: clone 5 #======Platform shared values ======6 NUGET_RESTORE_SOURCE: ${NUGET_REPOSITORY_URL} 7 API_KEY: ${AUTH_TOKEN} 8 NUGET_PUBLISH_SOURCE: ${NUGET_REPOSITORY_URL} 9 CI_SCRIPTS: ${CI_PROJECT_DIR}/../../../../../ CIScripts 10 #======Solutions and projects ======11 SOLUTION:"AWebSys.Shared.WebViewBridge" 12 WEB_VIEW_BRIDGE:"WebViewBridge" 13 WEB_VIEW_BRIDGE_TESTS:"WebViewBridge.Tests" 14 WVB_ANDROID_CHROME:"WebViewBridge.Bridge. AndroidChrome" 15 WVB_CEFSHARP:"WebViewBridge.Bridge.CefSharp. WinForms" 16 WVB_WKWEBVIEW:"WebViewBridge.Bridge.WKWebView " 17 WVB_WKWEBVIEW_MAC:"WebViewBridge.Bridge. WKWebView.Mac" 18 WVB_HELPER_BRIDGE:"WebViewBridge.HelperBridge " 19 ANDROID_TEST_APP:"DroidTestApp" 20 IOS_TEST_APP:"IOSTestApp" 21 MAC_TEST_APP:"MacTestApp" 22 WIN_TEST_APP:"WinTestApp"

Listing 5.8: Definice proměnných v souboru .gitlab-ci.yml včetně nastavení klonovací Git strategie.

Definice fází Pro projekt WebViewBridge je definováno celkem 6 fází:

52 5. Implementace

1. build-no_dependencies – V této fázi jsou kompilovány všechny projekty, které nemají žádné závislosti na jiných projektech v řešení WebViewBridge. 2. build-dependecies_level_1 – Zde dochází k sestavení všech projektů závislých na některém z projektů z předešlé fáze. 3. build-dependecies_level_2 – V rámci této skupiny úkolu do- chází ke kompilaci všech projektů, které mají závislosti na projektech z předešlých dvou fází. 4. build-examples – Kompilovány jsou testovací aplikace pou- žívající některý z knihovních projektů sestavených v pře- dešlých fázích. 5. test – Dochází ke spuštění a vyhodnocení všech dostup- ných jednotkových testů. Typicky jednotkové testy určené pro projekty kompilované v prvních třech fázích. 6. deploy – Jediná fáze, která se neprovádí vždy, ale pouze jsou-li změny nahrány z větve develop, prerelease, release nebo master. V rámci této fáze se vytváří a publikují, tj. posílají do cílové destinace, NuGet balíčky z některých projektů kompilovaných v prvních třech fázích.

Fáze byly zvoleny tak, aby zajistily jistou míru čitelnosti s cílem mít rychlý přehled o dílčích prováděných úkolech logicky uspo- řádaných do skupin. Současně výstupy, tzv. artefakty, úkolů mohou být použity v úkolech fází následujících. Defini fází je možné najít v ukázce 5.9.

1 stages: 2 - build-no_dependencies 3 - build-dependencies_level_1 4 - build-dependencies_level_2 5 - build-examples 6 - test 7 - deploy Listing 5.9: Definice fází v souboru .gitlab-ci.yml použitého pro projekt WebViewBridge.

53 5. Implementace

Definice šablon Šablonami se rozumí speciální úkoly, které jsou neviditelné pro GitLab runner, tj. úkoly které se de facto používají jako pomocné funkce úkolů, které již GitLab runner vidí a provádí. Typicky se používají k definování společných či základních vlastností a nastavení úkolů, které vytváří jistou výchozí kostru3 těchto úkolů. Definice každé šablony začíná symbolem „.“ (tečka) následovaný názvem daného úkolu. Jednotlivé úkoly se mezi sebou mohou vzájemně rozšiřovat, doplňovat či se na sebe mohou odkazovat. Pro tento účel se používá klíčové slovo extends. V ukázce 5.10 ze souboru se nachází .gitlab-ci.yml definice dvou šablon, které jsou použity pro úkoly zaměřené na kompilování zdrojového kódu. Šablony jsou určeny pro použití v úkolech, které mají být prováděny na operačním systému Windows. Z této ukázky stojí za zmínku především blok script, ve kterém se definují všechny příkazy, které se mají provést. Zde jeale potřeba pamatovat na fakt, že tyto příkazy se provádí v běho- vém prostředí agenta GitLab runner, a tudíž je potřeba příkazy psát ve správné syntaxi daného běhového prostředí. Ukázka s definicí dvou šablon se stejným účelem, ale určených pro použití v operačním systému macOS, se nachází v příloze A.7.

1 . win_build: 2 before_script: 3 - chcp 65001 4 script: 5 - '"%CI_SCRIPTS%/win10_build.bat"-project"% PROJECT%"-config"%CONFIG%"-platform"% PLATFORM%"-buildrefs"%BUILDREFS%" ' 6 variables: 7 BUILDREFS:"False" 8 PLATFORM:"AnyCPU" 9 dependencies:[] 10 artifacts: 11 when: always 12 paths:

3. Odtud označení šablona.

54 5. Implementace

13 - '%SOLUTION%/nugets_restore.log ' 14 - '%PROJECT_BIN% ' 15 expire_in: '4 days ' 16 tags: 17 - windows10 18 19 .win_develop_build: 20 extends: .win_build 21 variables: 22 CONFIG:"Debug" 23 only: 24 - develop Listing 5.10: Definice šablon pro Windows.

Definice úkolů Sekce obsahuje definici všech úkolů, které GitLab runner vidí a může je provést. V ukázce 5.11 je definován úkol, jehož účelem je provést kompilaci zdrojového kódu projektu WebViewBridge.Bridge.AndroidChrome, který je součástí řešení WebViewBridge. Z této ukázky nemusí být na první pohled zřejmé, co tento úkol ve skutečnosti dělá. Klíčové je zde použití funkce extends. Tou se v tomto případě defínuje, že úkol s názvem build:debug:develop:android_chrome rozšiřuje a používá šablonu .win_develop_build, která dále ještě rozšiřuje šablonu .win_build, přičemž definici obou šablon lze najít v ukázce 5.10. Při zpracování a vyhodnocení konfigurač- ního souboru .gitlab-ci.yml tak dojde k vytvoření úkolu, jehož definice by vypadala jako v ukázce 5.12.

1 build:debug:develop:android_chrome: 2 extends: .win_develop_build 3 stage: build-dependencies_level_2 4 dependencies: 5 - build:debug:develop:web_view_bridge 6 - build:debug:develop:helper_bridge 7 variables: 8 PROJECT:"${WVB_ANDROID_CHROME}" 9 PROJECT_BIN:"${SOLUTION}/${WEB_VIEW_BRIDGE }/Bridge/${WVB_ANDROID_CHROME}/bin"

55 5. Implementace

Listing 5.11: Úkol build:debug:develop:androidchrome : pedvyhodnocenmfunkceextends.

1 build:debug:develop:android_chrome: 2 stage: build-dependencies_level_2 3 before_script: 4 - chcp 65001 5 script: 6 - '"%CI_SCRIPTS%/win10_build.bat"-project"% PROJECT%"-config"%CONFIG%"-platform"% PLATFORM%"-buildrefs"%BUILDREFS%" ' 7 variables: 8 BUILDREFS:"False" 9 PLATFORM:"AnyCPU" 10 CONFIG:"Debug" 11 PROJECT:"${WVB_ANDROID_CHROME}" 12 PROJECT_BIN:"${SOLUTION}/${WEB_VIEW_BRIDGE }/Bridge/${WVB_ANDROID_CHROME}/bin" 13 dependencies: 14 - build:debug:develop:web_view_bridge 15 - build:debug:develop:helper_bridge 16 artifacts: 17 when: always 18 paths: 19 - '%SOLUTION%/nugets_restore.log ' 20 - '%PROJECT_BIN% ' 21 expire_in: '4 days ' 22 only: 23 - develop 24 tags: 25 - windows10

Listing 5.12: Úkol build:debug:develop:androidchrome : povyhodnocenfunkceextends..

Konfigurační YAML soubor obsahuje definice úkolů s různým zaměřením. Kromě kompilování zdrojového kódu obsahuje i úkoly pro spouštění jednotkových testů a jejich vyhodnocení a pro tvorbu a publikování NuGet balíčků. Ukázky takových úkoly jsou k nalezení v přílohách v podsekci A.4.1.

56 5. Implementace 5.4 Překážky k vyřešení

5.4.1 Konfigurace nástroje GitLab runner Při konfiguraci nástroje GitLab runner (viz 4.3.1) se v první řadě vycházelo z předpokladů uvedených v návrhu, který je k nalezení v sekci 4.8. Vznikla tak síť počítačů vyhrazených pro účely průběžné integrace. Tvořena byla stroji používanými pro vývoj aplikací na platformě .NET a Xamarin, které měly již všechny potřebné nástroje k provádění nezbytných úkolů k dispozici. Součástí této sítě bylo celkem 8 počítačů, z nichž 7 běželo na ope- račním systému Windows a pouze jeden stroj na operačním systému macOS. Na každém z nich byl nainstalován specifický agent GitLab runner s běhovým prostředím shell s možností až dvou jeho současně běžících instancí, které mohly provádět konkrétní úkoly. V jeden okamžik tak mohlo být spuštěno nejvýše 16 agentů GitLab runner, tj. v jednom okamžiků mohlo být paralelně vykonáváno až 16 úkolů. Toto schéma se používalo po dobu několika týdnů. Nakonec se však ukázalo, že toto řešení není z mnoha důvodů zcela vhodné:

• Efektivita – Instalací a spuštěním agentů na daných fyzických strojích došlo k jejich okamžitému citelnému zpomalení, které bylo zapříčiněno tím, že agent GitLab runner může pro vyko- nání některých úkolů v rámci průběžné integrace vytěžovat značné množství zdrojů počítače. Protože se na daných strojích současně vyvíjely i samotné aplikace, mělo zpomalení počítačů dopad i na efektivitu vývoje. Na stroji s operačním systémem macOS se také pravidelně stávalo, že úkol prováděný v rámci GitLab CI/CD skončil chybou, protože na disku počítače došlo volné místo. Tento problém byl způsoben v důsledku souhry 3 hlavních faktorů: GitLab runner spotřebovával paměť pro dočasné uchování dat, jako jsou NuGet balíčky, binární soubory ad., programátoři na stroji vyvíjeli, čímž produkovali data, která potřebovali mít někde uložena, a nakonec velikost disku stroje byla jen 128 GB.

• Bezpečnost – Nástroje GitLab runner byly instalovány s bě- hovým prostředím shell, tzn. že využívaly přímo prostředí

57 5. Implementace

fyzického stroje. To ve výsledku znamenalo, že na jednu stranu mohl GitLab runner ovlivňovat při špatném nastavení povahu dat na stroji. A i když se toto nedělo, na stranu druhou mohl naopak data, která agent používal, ovlivňovat programátor svými zásahy. Stávalo se, že v okamžiku, kdy uživatel na stroji pracoval ve stejném adresáři jako agent, pak GitLab runner někdy končíval chybou a úkol neprovedl.

• Vlastnosti běhového prostředí – Aby bylo možné spolehnout se na výsledky operací prováděných v rámci průběžné integrace, bylo zapotřebí zajistit, aby prostředí na všech těchto strojích bylo vždy stejné. To se v okamžiku nasazení agentů podařilo. Avšak v průběhu času se stávalo, že se jeden úkol provedl na dvou strojích s různým výsledkem. Příčinou byla nekonzistence vlastností jednotlivých prostředí, která mohla být způsobena záměrnými změnami jako doinstalování potřeb- ných nástrojů, platforem ad. s opomenutím některého stroje, anebo nevědomými mezi které lze zařadit změny provedené samotnými programátory. Toto řešení nakonec bylo nahrazeno jiným, které je popsané v podsekci 5.3.1.

5.4.2 Práce s NuGet balíčky V době, kdy se začala realizovat praktická část této práce, se ve firmě pro vývoj mobilních aplikací na platformě Xamarin používal přístup využívající rámec MvvmCross (viz 3.1) s jádrem postaveným na plat- formě .NET Framework ve verzi 4.6.1. Ten se stal ve firmě základem pro většinu projektů vyvíjených na platformě .NET. Pro tento stav vzniklo i první funkční řešení, které pro práci s Nu- Get balíčky používalo nástroj nuget. Avšak v době, kdy toto řešení bylo vytvořeno a odzkoušeno, a tudíž připraveno k nasazení, se čím dál více do popředí dostával nový .NET Standard 2.0, který se měl v příštích letech stát standardem pro vývoj na platformě .NET. Kromě tohoto důvodu byly projekty stále v raných fázích, tudíž se předpokládalo, že přechod by neměl být složitý. Posledním, ale o to důležitějším důvodem, proč došlo ve firmě k rozhodnutí, že by se měly všechny .NET Framework projekty převést na použití .NET

58 5. Implementace

Standard 2.0, byla výkonnost nástroje nuget při obnovování NuGet balíčků. Jako centrální úložiště NuGet balíčků se ve firmě používá nástroj Nexus OSS, který současně funguje i jako proxy. Díky tomu je většina NuGet balíčků dostupná z lokální sítě a stahování i nahrávání NuGet balíčků je mnohem rychlejší a stabilnější. Avšak i přesto se občas stávalo, že se některé Nuget balíčky nepodařilo úspěšně stáhnout. Mohl za to fixní časový interval nástroje nuget pro stažení a zpracováníí jednoho NuGet balíčku, který je 2 sekundy. Pro práci s NuGet balíčky u .NET Standard 2.0 projektů je určen nástroj dotnet, jehož časový interval pro stažení a zpracování jednoho NuGet balíčku je 100 sekund. Tento program podporuje přístup označovaný jako PackageReference, tj. závislosti na jednotlivých NuGet balíčcích jsou uvedeny přímo v souboru .csproj. Tento přístup by měl být mnohem výkonější než použití Packages.config, a také umožňuje po- užití tranzitivních závislostí, čímž se ve výsledku může velmi značně zredukovat počet závislostí napříč celým řešením. Pro úspěšný přechod z knihovny .NET Framework na .NET Stan- dard 2.0 bylo zapotřebí vyřešit následující problémy: 1. Zajištění plné podpory .NET Standard 2.0 – Všem projektům, u kterých je to možné, nahradit .NET Framework 4.6.1. za .NET Standard 2.0. U ostastních (například WPF, Xamarin.iOS, Xamarin.Mac, Xamarin.Android) aktulizovat verze platforem, aby plně podporovaly .NET Standard 2.0. 2. Nahrazení nástroje nuget programem dotnet – K úspěšnému nahra- zení je u projektu postavených na platformách .NET Framework či Xamarin zapotřebí vyřešit následující kroky: (a) Převedení Packages.config na PackageReference – Nástroj nuget pracuje s xml souborem označeným packages.config, který obsahuje informace o všech závislostech týkajících se Nu- Get balíčků. Program dotnet neumí pracovat se souborem packages.config. Místo toho pracuje s novým formátem souboru .csproj, který obsahuje všechny informace o instalo- vaných NuGet balíčcích4.

4. Tento přístup se označuje PackageReference.

59 5. Implementace

(b) Zrušení statického AssemblyInfo.cs souboru – Cílem této změny je přenést všechny metainformace o projektu do .csproj souboru, odkud je čte a dále používá nástroj dotnet. Při kompilaci takového projektu se vždy generuje nový soubor AssemblyInfo.cs. (c) Sjednocení umístění NuGet balíčků – Nástroj nuget používá jako přednastavenou cílovou destinaci pro NuGet balíčky, kam je stahuje, adresář ${SolutionFolder}/packages/, kdežto nástroj dotnet stahuje NuGet balíčky do adresáře ${User- Home}/.nuget/, který zároveň představuje lokální cache NuGet balíčků. Z pohledu průběžné integrace je však lepší řešení použít umístění ${SolutionFolder}/packages/, tj. držet balíčky pouze uvnitř lokálního repozitáře, nad kterým operuje GitLab runner, aby se jednotlivé instance nástroje GitLab runner vzájemně neovlivňovaly při vykonávání úkolů. (d) Zajistit správné fungování tvorby NuGet balíčků – K zajištění podpory správného fungování operace pack používané pro vytváření nových NuGet balíčků u projektů postave- ných na platformách .NET Framework nebo Xamarin, je potřeba: i. NuGet.Build.Tasks.Pack – NuGet balíček, který je důle- žitý pro použití nástroje dotnet a operaci pack a který zajistí, že je projekt správně sestaven a zpracován při tvorbě NuGet balíčku. ii. Přidat funkci IncludeReferencedProjects z nástroje nuget – U programu nuget je možné použít parametr Inclu- deReferencedProjects, který u projektu, ze kterého se vytváří NuGet balíček, vyřeší všechny jeho závislosti na jiných projektech tak, že je zkompiluje a vytvořené .dll soubory zahrne přímo do výsledného balíčku, tj. balíček tak bude zahrnovat funkce daných projektů přímo. Toto nastavení se používá, když z referenco- vaných projektů není žádoucí vytvářet samostatné NuGet balíčky a de facto se jedná pouze o „pomocné“ projekty. Nástroj dotnet však žádný takový parametr nemá a sám o sobě neumí závislosti vyřešit tímto

60 5. Implementace

způsobem. Naopak, pokud projekt, ze kterého se vy- tváří NuGet balíček používá jiný projekt, pak dotnet každý takový projekt označí jako závislost v metada- tech NuGet balíčku, tj. u vytvořeného NuGet balíčku bude uvedena informace o nutnosti nainstalovat také NuGet balíček, který odpovídá projektu, který byl re- ferencován, a to v konečném důsledku vede k nutnosti vytvořit NuGet balíček z každého projektu, na který se původní projekt, ze kterého chceme NuGet balíček vytvořit, odkazuje. iii. Používání přípon u názvu balíčku – Dle přítomnosti pří- pon ve verzi NuGet balíčku, která je součástí jeho názvu, se rozlišuje, zda se jedná o oficiální verzi Nuget balíčku, anebo pouze o předběžnou verzi. Nástroj dotnet umožňuje nastavit příponu při vytváření NuGet balíčku skrze parametr suffix. Bohužel, při zadání tohoto parametru z příkazového řádku, se jeho hodnota nepoužije správně a výsledný NuGet balíček v názvu zadanou příponu neobsahuje.

Všechny uvedené body, které představovaly zásadní překážky při přechodu z rozhraní .NET Framework na .NET Standard 2.0 se nakonec podařilo úspěšně vyřešit. Místo nástroje dotnet výsledné řešení pracuje s programem msbuild, který vnitřně dotnet používá. Důvodem je, že dotnet (minimálně) ve verzi 2.1.202 a jeho operace pack a restore nelze použít pro Xamarin.Android projekty, ale msbuild funguje. Stále však pro jednu operaci nebylo možné použít nástroj msbuild, který danou operaci nepodporuje, ale nuget ano. Jedná se o operaci push, která slouží k nahrání NuGet balíčků na požadované cílové místo. Z toho důvodu je potřeba vždy zajistit přítomnost tohoto nástroje na všech strojích, na kterých běží agent GitLab runner a který má být použitelný Popis, jak se podařilo vyřešit jednotlivé výše uvedené kroky, je k nalezení v přílohách v sekci A.5.

61 6 Vyhodnocení

V první části této kapitoly jsou popsány dílčí oblasti, které se dle ná- vrhu řešení podařilo vytvořit. Současně je zde také zhodnoceno, zda se řešení konkrétní části podařilo také úspěšně integrovat do vývojových procesů firmy. Tato část není zaměřena na konkrétní projekt, ale spíše shrnuje všechna nasazená řešení ve firmě. Ve druhé části kapitoly je zhodnocen stav procesů vývoje ve firmě na platformě Xamarin po integraci implementovaného řešení v projektu Anakin.

6.1 Dosažené výsledky

Cílem implementace praktické části bylo vyřešit následující body:

1. Sjednotit a zjednodušit práci při verzování zdrojového kódu použitím zvoleného modelu GitFlow,

2. vytvořit skriptovací soubory, které zajistí automatické kompilo- vání a testování zdrojového kódu pomocí jednotkových testů,

3. použít nástroj StyleCop Analyzers pro automatickou kontrolu kvality kódu a vhodným způsobem tomuto nástroji nastavit pravidla, proti kterým by měl testovat kód,

4. vhodným způsobem nakonfigurovat nástroj GitLab CI/CD pro nasazení průběžné integrace či průběžného nasazení.

Konečné řešení, které se podařilo úspěšně integrovat do vývojo- vých procesů a dnes se každodenně používá ve čtyřech projektech ve firmě A-WebSys, má následující vlastnosti:

Git a GitFlow Pro systém Git byla vytvořena sada pravidel dle konvencí a nej- lepších praktik popisující, jakým způsobem je třeba ho používat. Účelem těchto pravidel je sjednotit jeho použití a eliminovat nežádoucí stavy v historiích repozitářů. A dále zlepšit čitelnost a relevanci informací popisující jednotlivé revize. K řízení ver- zování byl použit upravený model GitFlow, který je však v textu

62 6. Vyhodnocení

dále odkazovaný jako GitFlow. Tento model, který k původní strategii GitFlow navíc přidává větev prerelease, která pokrývá mezistav větví release a develop, byl úspěšně nasazen do vývojo- vých procesů jako úplně první ze všech částí řešení. Skriptovací soubory Celkem bylo vytvořeno 8 skriptů, z nich jsou 4 dávkové soubory určené pro operační systém Windows a pro práci s Windows a Android projekty a zbylé 4 shell soubory jsou určené pro operační systém macOS a práci s iOS a macOS projekty. Skripty zajišťují automatizaci kompilace, obnovení, vytváření a zveřej- nění NuGet balíčků a spouštění jednotkových testů. Skripty je možné bez úprav přenášet mezi stroji a na nich je bez problémů používat. Více informací v sekci 5.2. Průběžná integrace, průběžné nasazení Řešení průběžné integrace se podařilo nasadit u projektu Ana- kin (viz sekce 4.1). V tomto řešení se po každé operaci git push spustí ověření, zda je kód kompilovatelný a prochází všemi do- stupnými jednotkovými testy. U ostatních tří projektů, mezi ni- miž je i projekt WebViewBridge (viz úvod kapitoly 5), se dokonce podařilo vytvořit řešení pro průběžné nasazení. To znamená, že pro každou operaci git push provedenou z větví develop, prerelease, release a master se kromě ověření kódu provede i kompletace v podobě vytvoření NuGet balíčků a jejich automatického na- hrání do sdíleného repozitáře, odkud jsou okamžitě všem ve firmě dostupné. Dle větve, ze které byly změny nahrány, obsa- hují výsledné NuGet balíčky v názvu příponu označující zda se jedná o beta či alfa verze, nebo jsou bez přípony označující verze ostré. Nasazená řešení pro průběžnou integraci i průběžné nasazení v sobě plně integrují upravený model GitFlow. Pro kontrolu kvality kódu bylo vytvořeno řešení (viz sekce 5.1), které bylo dokonce u všech projektů nasazeno a nějakou dobu po- užíváno, avšak nakonec se neshledalo s úspěchem a bylo ze všech projektů staženo. Hlavními důvody neúspěchu byly: • Nastavená pravidla – Snahou při nastavení pravidel pro kontrolu stylu psaní kódu bylo komunikovat změny se všemi členy vý- vojového týmu. Avšak pravděpodobně i ve spojení s bodem

63 6. Vyhodnocení

následujícím se nepodařilo nastavit pravidla do optimálního či alespoň vyhovujícího stavu tak, aby byli všichni spokojeni. To ve výsledku vedlo k nespokojenosti týmu a zpomalení samotného vývoje.

• MvvmCross – Při použití tohoto rámce se používají automaticky generované kusy kódu dle dostupné šablony. Výsledný kód však nesplňoval nastavená pravidla a bohužel se konkrétní třídy či metody nedaly z kontroly vyjmout. Pravidla se kvůli tomu nepodařilo dostat do požadovaného stavu.

• Přechod z .NET Framework na .NET Standard – Tímto přecho- dem vyvstala řada překážek (viz sekce 5.4), které měly větší prioritu řešení. V době, kdy se pracovalo na řešení, které by fungovalo pro .NET Standard, se rozhodlo o stažení použití nástroje StyleCop Analyzers. Než se podařilo všechny kritické překážky vyřešit, posunuly se projekty významně dopředu a s tím i přibylo spoustu nového kódu. K nasazení jiného řešení pro kontrolu kvality kódu by bylo potřeba mít dostatek prostoru k provedení nutného přeskládání kódu tak, aby splňoval požadovaná pravidla.

6.2 Srovnání s původním stavem

Hlavní přínos provedených změn spočívá v nasazení průběžné integrace. Její integrací bylo dosaženo odstranění nutnosti lidského zásahu do procesu ověřování správnosti kódu. Dalším přínosem je, že toto ověřování může provádět i člověk, který v danou chvíli nemá k dispozici počítač s potřebnými nástroji ke kompilaci a otestování zdrojového kódu. Každá změna nahrána do centrálního repozitáře GitLab je takto otestována. Díky propojení nástrojů GitLab a GitLab CI/CD se výrazně snížilo riziko integrace nežádoucích, tj. nezkompi- lovatelných či neprocházejících testy, změn. Ač je hlavním úkolem průběžné integrace hlavně ověřit správnost kódu, výstupem jsou zkompilované binární soubory aplikací, které jsou správně nastavené a použitelné pro jejich kompletaci. Tím se celý proces nasazení sám o sobě moc nezrychlil, avšak došlo ke snížení počtu výskytů chyb v této oblasti.

64 6. Vyhodnocení

Integrováním upraveného modelu GitFlow se výrazně zlepšila flexibilita vývoje na platformě Xamarin. Pro vyhodnocení byly použité stejné ukazatele, zdroj i stejně dlouhý časový úsek jako při vyhodnocení procesů před integrací tohoto řešení (viz 4.1.2). Tento časový úsek však odpovídá 75 dnům po nasazení kompletního konečného řešení, tj. bez automatické kontroly kvality kódu, do vývojových procesů firmy. Ze získaných dat vyplývá, že se denně integrují zhruba 3 změny, což znamená, že se teď integruje o jednu změnu v kódu více než před zavedením implementovaného řešení. Při nasazování aplikace do produkce nastala chyba pouze jednou. Tato chyba byla způsobena zapomenutým zvýšením verze aplikace a zjištěna při její kompletaci. Jako pozitivní vedlejší vliv nasazení průběžné integrace je zlepšení pokrytí zdrojového kódu jednotkovými testy.

65 7 Závěr

Cílem této diplomové práce bylo zefektivnit procesy mobilního vý- voje na platformě Xamarin ve společnosti A-WebSys spol. s r.o., a to zejména prostřednictvím automatizace vhodných procesů vývoje. Dle požadavků kladených na tuto práci jsem se snažil od začátku jejího vypracování zaměřit především, ale ne jen, na procesy spojené s verzováním, kontrolou kvality a testováním zdrojového kódu. Konečné řešení, které se podařilo úspěšně nasadit ve firmě a dnes se používá pro každodenní práci u čtyř firemních projektů, zjednodu- šuje a zpřehledňuje integrování změn díky použití modelu GitFlow, a tím zlepšuje celkovou spolupráci v týmu. U produkčního projektu Anakin (viz sekce 4.1) se podařilo zavést a úspěšně se používá řešení pro průběžnou integraci, která při každém nahrání změn v kódu na server GitLab provede jeho automatickou kompilaci a spustí nad ním jednotkové testy. U ostatních tří projektů, které představují knihovny používané právě v projektu Anakin a z nichž jedna je také vyvíjena na platformě Xamarin, se podařilo dokonce zavést řešení průběžného nasazení. Vý- stupem těchto projektů jsou NuGet balíčky, které jsou v požadovaných místech zpracování v repozitáři automaticky i vytvořeny a nahrány do firemního repozitáře. Z tohoto místa jsou po nahrání ihned všem vývojářům dostupné a připravené k použití. Ve firmě se na krátkou dobu podařilo nasadit i řešení pro automatickou kontrolu kvality kódu s využitím nástroje StyleCop Analyzers (viz podsekce 4.4.1), nicméně toto řešení se neshledalo s úspěchem a bylo staženo. Detailnější popis dosažených výsledků se nachází v sekci 6.1. V rámci této práce byly okrajově řešeny i otázky automatické správy verzí kódu či automatické distribuce aplikace ke koncovým uživatelům, či minimálně k živým testerům dle návrhu uvedeného v podsekci 4.8.1. Do budoucna by tak toto řešení mohlo být rozšířeno o automatizaci těchto kroků. Výsledky této práce, včetně seznámení se samotnou implementací, možnostmi využití a popis jeho použití, byly ve společnosti A-WebSys již prezentovány v rámci firemního školení.

66 7. Závěr

Všechna nasazená řešení však výrazným způsobem eliminují zá- sah člověka do procesu ověřování správnosti kódu a tím snižují počet chyb. Sdílený kód, tj. kód nahraný do repozitáře GitLab je vždy otes- tovaný, a to vždy za stejných podmínek. Kromě implementace praktické části jsou v této práci zmapovány a popsány možnosti integrace automatizace procesu distribuce aplikace k živým testerům či do produkčního prostředí (viz sekce 4.6 a podsekce 4.8.1), a také možnosti sběru dat z klientských zařízení, jako je zpětná vazba či informace o chybách v aplikaci (viz sekce 4.7). Ačkoli všechny popsané procesy nebyly úspěšně zařazeny mezi vývojové procesy firmy A-WebSys spol. s r.o., jejich analýza a popis jsou připraveny k potenciálnímu přehodnocení a možnému nasazení v budoucnu.

67 Bibliografie

1. COLLINS–SUSSMANS, Ben; W. FITZPATRICK, Brian; PILATO, C. Michael. Version Control with Subversion: For Subversion 1.7.: (Compiled from r5650) [online]. c2002–2013 [cit. 2018-03-30]. Do- stupné z: http://svnbook.red-bean.com/en/1.7/svn-book. pdf. 2. CHACON, Scott. Pro Git. 1. výdání, 2009. Praha: CZ.NIC, z. s. p. o., c2009 Scott Chacon. 2. publikace v Edici CZ.NIC. ISBN 978-80-904248-1-4. 3. MARR, Bernard. Key Performance Indicators For Dummies. The Atrium, Southern Gate, Chichester, Západní Sussex, Spojené Království: A Wiley Brand. John Wiley & Sons Ltd, c2015 John Wiley & Sons Ltd. ISBN 978-1-118-91325-3. 4. HUMBLE, Jez; FARLEY, David. Continuous Delivery: Reliable Soft- ware Releases Through Build, Test, and Deployment Automation. Bos- ton: Addison-Wesley, c2011 Pearson Education Inc. ISBN 978–0–321–60191–9. 5. Comparing workflows: Centralized Workflow [online]. Atlassian Bit- Bucket [cit. 2018-03-30]. Dostupné z: https://www.atlassian. com/git/tutorials/comparing-workflows#centralized-workflow. 6. CHRISTENSEN, Spencer. Git Workflows That Work [online]. End Point, 2014-05-02 [cit. 2018-03-30]. Dostupné z: https://www. endpoint.com/blog/2014/05/02/git-workflows-that-work. 7. PAVELKA, Jiří. Git Flow v praxi [online]. InstallFest. Vyrobilo AVC Silicon Hill, 2017 [cit. 2018-03-30]. Dostupné z: https:// www . youtube . com / watch ? v = Av0XC3hAZVY & index = 11 & list = PLub6xBWO8gV_t_p-5-J_qU20fkkDtsLjB. 8. GitHub Guides: Understanding the GitHub Flow [online]. GitHub.com, 2017 [cit. 2018-04-01]. Dostupné z: https://guides.github.com/ introduction/flow/ . aktual. 2017-11-30. 9. Comparing workflows: Git Feature Branch Workflow [online]. At- lassian BitBucket [cit. 2018-03-30]. Dostupné z: https://www. atlassian.com/git/tutorials/comparing-workflows/feature- branch-workflow. 10. Comparing workflows: Gitflow Workflow [online]. Atlassian BitBucket [cit. 2018-03-30]. Dostupné z: https://www.atlassian.com/git/ tutorials/comparing-workflows/gitflow-workflow.

68 BIBLIOGRAFIE

11. DRIESSEN, Vincent. A successful Git branching model [online]. 2010- 01-05 [cit. 2018-04-01]. Dostupné z: http://nvie.com/posts/a- successful-git-branching-model/. 12. Comparing workflows: Forking Workflow [online]. Atlassian BitBucket [cit. 2018-03-30]. Dostupné z: https://www.atlassian.com/git/ tutorials/comparing-workflows/forking-workflow. 13. SIJBRANDIJ, Sytse. GitLab Flow [online]. GitLab Inc., 2014-09-24 [cit. 2018-04-03]. Dostupné z: https://about.gitlab.com/2014/ 09/29/gitlab-flow/. 14. PIPINELLIS, Achilleas. Getting started with GitLab and GitLab CI [online]. GitLab Inc., 2015-12-14 [cit. 2018-11-14]. Dostupné z: https://about.gitlab.com/2015/12/14/getting-started- with-gitlab-and-gitlab-ci/. 15. GitLab Continuous Integration (GitLab CI/CD) [online]. GitLab Inc. [cit. 2018-11-14]. Dostupné z: https://docs.gitlab.com/ee/ci/ Kapitola v dokumentaci GitLab. 16. GitLab Continuous Integration & Delivery: GitLab has integrated CI/CD pipelines to build, test, deploy, and monitor your code [online]. GitLab Inc. [cit. 2018-11-14]. Dostupné z: https://about.gitlab. com/product/continuous-integration/. 17. Configuring GitLab Runners [online]. GitLab Inc. [cit. 2018-11-14]. Dostupné z: https : / / docs . gitlab . com / ee / ci / runners / README.html Podkapitola v dokumentaci GitLab. 18. Configuration of your jobs with .gitlab-ci.yml [online]. GitLab Inc. [cit. 2018-11-14]. Dostupné z: https://docs.gitlab.com/ee/ci/ yaml/ Podkapitola v dokumentaci GitLab. 19. RIBEIRO, Rob. Making CI easier with GitLab [online]. GitLab Inc., 2017-07-13 [cit. 2018-11-14]. Dostupné z: https://about.gitlab. com/2017/07/13/making-ci-easier-with-gitlab/. 20. Getting started with GitLab CI/CD [online]. GitLab Inc. [cit. 2018- 11-14]. Dostupné z: https://docs.gitlab.com/ee/ci/quick_ start/ Podkapitola v dokumentaci GitLab. 21. Introduction to pipelines and jobs [online]. GitLab Inc. [cit. 2018-11- 15]. Dostupné z: https://docs.gitlab.com/ee/ci/pipelines. html Podkapitola v dokumentaci GitLab.

69 BIBLIOGRAFIE

22. Requirements: GitLab Runner [online]. GitLab Inc. [cit. 2018-11- 14]. Dostupné z: https : / / docs . gitlab . com / ee / install / requirements.html#gitlab-runner Podkapitola v dokumentaci GitLab. 23. TRZCIŃSKI, Kamil. Security of running jobs [online]. GitLab Inc., 2017-09-18 [cit. 2018-11-15]. Dostupné z: https://gitlab.com/ gitlab- org/gitlab- runner/blob/master/docs/security/ index.md. 24. VRIES, Reinder de. How To Develop iOS Apps On A Windows PC [online]. LearnAppMaking.com, 2018-06-21 [cit. 2018-11-16]. Dostupné z: https://learnappmaking.com/develop-ios-apps- on-windows-pc/#virtualization. 25. Jenkins [online]. jenkins.com [cit. 2018-12-02]. Dostupné z: https: //jenkins.io/. 26. PIHRT, Josef. Roslynator [online]. Github.com [cit. 2018-12-02]. Dostupné z: https://github.com/JosefPihrt/Roslynator. 27. DORSEY, Terrence. Visual Studio Toolbox: Code Analysis, Profiling and Refactoring Tools for Visual Studio 2017 [online]. Media Inc., 2017-10-26 [cit. 2018-12-02]. Dostupné z: https://visualstudiomagazine. com/articles/2017/10/01/code-analysis.aspx. 28. WARREN, Genevieve; LU, Gen. Visual Studio Docs: Install FxCop analyzers in Visual Studio [online]. Microsoft, 2018-03-08 [cit. 2018- 12-02]. Dostupné z: https : / / docs . microsoft . com / en - us / visualstudio / code - quality / install - fxcop - analyzers ? view=vs-2017. 29. WARREN,Genevieve; RATH, Banani. Visual Studio Docs: Frequently asked questions about FxCop and FxCop analyzers [online]. Micro- soft, 2018-06-09 [cit. 2018-12-02]. Dostupné z: https : / / docs . microsoft.com/en- us/visualstudio/code- quality/fxcopanalyzers-faq?view=vs-2017. 30. DORSEY, Terrence. Visual Studio Toolbox: 16 New Code Analy- sis, Testing and Debugging Tools For Visual Studio 2017 [online]. Media Inc., 2018-05-17 [cit. 2018-12-02]. Dostupné z: https:// visualstudiomagazine.com/articles/2018/05/01/vs-analysis- tools.aspx. 31. GCop [online]. Geeks Ltd. [cit. 2018-12-02]. Dostupné z: https: //github.com/Geeksltd/GCop.

70 BIBLIOGRAFIE

32. StyleCop Analyzers [online]. DotNetAnalyzers [cit. 2018-12-02]. Do- stupné z: https://github.com/DotNetAnalyzers/StyleCopAnalyzers. 33. MORLION, Peter. StyleCop: A Detailed Guide to Starting and Using It [online]. SubMain.com, 2018-04-10 [cit. 2018-12-02]. Dostupné z: https://blog.submain.com/stylecop-detailed-guide/. 34. StyleCop Analyzers: Documentation [online]. DotNetAnalyzers [cit. 2018-12-02]. Dostupné z: https://github.com/DotNetAnalyzers/ StyleCopAnalyzers/tree/master/documentation. 35. WENZEL, Maira et al. .NET Standard [online]. Microsoft, 2019-02- 25 [cit. 2018-12-02]. Dostupné z: https://docs.microsoft.com/ en-us/dotnet/standard/net-standard. 36. NANDWANI, Karan; BROCKSCHMIDT, Kraig; BOMMARITO, Scott; ULLRICH, Martin Andreas; WENZEL, Maira; JAIN, Ashish. Migrate from packages.config to PackageReference [online]. Micro- soft, 2018-03-27 [cit. 2018-12-02]. Dostupné z: https : / / docs . microsoft.com/en-us/nuget/reference/migrate-packages- config-to-package-reference. 37. NANDWANI, Karan; KOLEV, Nikolchev; JAIN, Ashish; ULL- RICH, Martin Andreas; WENZEL, Maira. NuGet pack and restore as MSBuild targets [online]. Microsoft, 2018-03-23 [cit. 2018-12- 02]. Dostupné z: https://docs.microsoft.com/en-us/nuget/ reference/msbuild-targets. 38. MLOEFFEN. dotnet build –version-suffix not working?: Komentář k řešené problematice [online]. github.com, 2017-05-04 [cit. 2018- 12-02]. Dostupné z: https://github.com/dotnet/cli/issues/ 3778. 39. AGRAWAL, Rohit. Feature: Allow project reference DLLs to be added to the parent nupkg for pack target like IncludeReferencedProjects in nuget.exe: Komentář k řešené problematice [online]. github.com, 2018- 03-29 [cit. 2018-12-02]. Dostupné z: https://github.com/NuGet/ Home/issues/3891#issuecomment-377319939. 40. DUNN, Craig; MCLEMORE, Mark; PLATT, Leah; JOHNSON, Justin; BRITCH, David. Preparing an Application for Release [online]. Microsoft, 2018-03-21 [cit. 2019-05-10]. Dostupné z: https:// docs.microsoft.com/en-us/xamarin/android/deploy-test/ release-prep/index?tabs=windows.

71 BIBLIOGRAFIE

41. SOFTWARE, Marino. Distributing apps to testers: A guide for app producers (and their clients) [online]. Marino Software, 2015-04- 24 [cit. 2019-04-28]. Dostupné z: https://medium.com/marino- software/distributing-apps-to-testers-7d00433cd86d. 42. Welcome to App Center: Continuously build, test, release, and monitor apps for every platform [online]. Microsoft [cit. 2019-05-08]. Dostupné z: https://appcenter.ms/. 43. Beta by Crashlytics: The Most Seamless Beta Distribution Experience for You and Your Testers [online]. Google Developers [cit. 2019-05- 08]. Dostupné z: https://try.crashlytics.com/beta/. 44. DUNN, Craig; MCLEMORE, Mark; ARAGONESES, Andres G.; BRITCH, David; ZAGAESKI, Brendan. Publishing to Google Play [online]. Microsoft, 2018-02-16 [cit. 2019-05-08]. Dostupné z: https: / / docs . microsoft . com / en - us / xamarin / android / deploy - test/publishing/publishing-to-google-play/index?tabs= windows. 45. DUNN, Craig; MCLEMORE, Mark; BRITCH, David; UMBAUGH, Brad. Publishing an Application [online]. Microsoft, 2018-02-16 [cit. 2019-05-08]. Dostupné z: https://docs.microsoft.com/en- us/xamarin/android/deploy-test/publishing/. 46. ZANON, Diego. How to distribute your enterprise mobile app? [online]. 2015-10-04 [cit. 2019-05-08]. Dostupné z: https://docs. microsoft.com/en-us/xamarin/android/deploy-test/publishing/. 47. GILLIAM, Erin. Top 11 Best Mobile In-App Feedback Tools: An Over- view [online]. 2017-11-22 [cit. 2019-05-08]. Dostupné z: https: //mopinion.com/top- 11- best- mobile- in- app- feedback- tools-an-overview/. 48. HelpStack: The Open Source Mobile Help Framework to support your iOS and Android app users [online]. HappyFox Inc., c2014 Happy- Fox Inc. [Cit. 2019-05-08]. Dostupné z: http://www.helpstack. io. 49. HelpShift [online]. HelpShift, c2019 [cit. 2019-05-08]. Dostupné z: https://www.helpshift.com/. 50. Instabug: In-App Feedback and Bug Reporting for Mobile Apps [online]. Instabug Inc., c2019 Instabug Inc. [Cit. 2019-05-08]. Dostupné z: http://www.helpstack.io. 51. ŽÁČEK, Jaroslav. Životní cyklus vývoje SW [online] [cit. 2019-05- 12]. Dostupné z: http://www1.osu.cz/~zacek/sweng/04.pdf.

72 BIBLIOGRAFIE

52. DevOps [online]. OMNICOM, s.r.o., c2008–2019 OMNICOM, s.r.o. [Cit. 2019-05-12]. Dostupné z: https://www.bestpractice.sk/ sk/Best-practice/DevOps.alej. 53. HÜTTERMANN, Michael. DevOps for Developers: Integrate development and operations, the agile way. Apress, c2012 Michael Hüttermann. ISBN 978-1-4302-4570-4. 54. FARCIC, Viktor. The DevOps 2.0 Toolkit: Automating the Continuous Deployment Pilpeline with Containerized Microservices. Cloud Bees, c2016 Viktor Farcic. 55. Vlastnosti prostredia DevOps [online]. OMNICOM, s.r.o., c2008– 2019 OMNICOM, s.r.o. [Cit. 2019-05-12]. Dostupné z: https:// www.bestpractice.sk/sk/Best-practice/DevOps/Vlastnosti- prostredia-DevOps.alej. 56. Prínosy DevOps [online]. OMNICOM, s.r.o., c2008–2019 OMNI- COM, s.r.o. [Cit. 2019-05-12]. Dostupné z: https://www.bestpractice. sk/sk/Best-practice/DevOps/Prinosy-DevOps.alej. 57. IRSHAD. What is Xamarin and its features: Xamarin Overview [online]. TechJini, 2017-01-27 [cit. 2019-05-12]. Dostupné z: https: //www.techjini.com/blog/xamarin-overview/. 58. Visual Studio Tools for Xamarin: Vytvářejte nativní aplikace pro An- droid, iOS a Windows s využitím jediného sdíleného základu kódu .NET [online]. Microsoft, c2019 Microsoft [cit. 2019-05-12]. Dostupné z: https://visualstudio.microsoft.com/cs/xamarin/. 59. DUNN, Craig; BRITCH, David; ANDERSON, Rick; BURNS, Amy. Introduction to mobile development [online]. Microsoft, 2017-03-28 [cit. 2019-05-12]. Dostupné z: https://docs.microsoft.com/en- us/xamarin/cross-platform/get-started/introduction-to- mobile-development. 60. DUNN, Craig; BRITCH, David; OSBORNE, John; POULAD. The Model–View–ViewModel Pattern [online]. Microsoft, 2017-07-08 [cit. 2019-05-12]. Dostupné z: https://docs.microsoft.com/ en - us / xamarin / xamarin - forms / enterprise - application - patterns/mvvm. 61. Getting Started with MvvmCross [online]. MvvmCross, c2019 Mvvm- Cross [cit. 2019-05-12]. Dostupné z: https://docs.microsoft. com/en-us/xamarin/xamarin-forms/enterprise-application- patterns/mvvm.

73 BIBLIOGRAFIE

62. A-WebSys [online]. c2003–2019 A-WebSys spol. s r.o. [Cit. 2019- 05-12]. Dostupné z: https://www.awebsys.cz/.

74 Seznam obrázků

4.1 Model strategie GitFlow [11]. 19 A.1 Přehled minimálních verzí jednotlivých .NET platforem pro podporu jednotlivých verzí rozhraní .NET Standard [35]. 97 A.2 Nastavení výchozího formátu NuGet balíčků na hodnotu PackageReference. 98 A.3 Zadání příkazu k odinstalování všech NuGet balíčku z konkrétního projektu v konzoli programu Visual Studio 2017. 100

75 Listings

5.1 Příkazy pro obnovení NuGet balíčků a vyhodnocení operace v souboru win10_nugets_restore.bat...... 42 5.2 Obnovení NuGet balíčků v souboru win10_build.bat... 44 5.3 Příkazy pro sestavení požadovaného projektu v souboru win10_build.bat...... 44 5.4 Vytvoření NuGet balíčků ze specifikovaných projektů v souboru win10_nuget_pack.bat...... 46 5.5 Nahrání vytvořených NuGet balíčků do cílové destinace v souboru win10_nuget_pack.bat...... 47 5.6 Spuštění jednotkových testů v souboru win10_nunit_unit_test.bat. 48 5.7 Konfigurační soubor config.toml nástroje GitLab runner použitý na počítači Mac mini Late 2012...... 50 5.8 Definice proměnných v souboru .gitlab-ci.yml včetně nastavení klonovací Git strategie...... 52 5.9 Definice fází v souboru .gitlab-ci.yml použitého pro projekt WebViewBridge...... 53 5.10 Definice šablon pro Windows...... 54 5.11 Úkol build:debug:develop:androidchrome : pedvyhodnocenmfunkceextends. 55 5.12 Úkol build:debug:develop:androidchrome : povyhodnocenfunkceextends.. 56 A.1 Blok příkazů pro obnovení NuGet balíčků a vyhodno- cení operace ze souboru macOS_nugets_restore.sh..... 90 A.2 Použití skriptu macos_nugets_restore.sh pro obnovení NuGet balíčků v souboru macos_build.sh...... 91 A.3 Blok příkazů pro sestavení požadovaného projektu a vy- hodnocení operace v souboru macos_build.sh...... 91 A.4 Blok příkazů pro vytvoření NuGet balíčků ze specifiko- vaných projektů v souboru macos_nuget_pack.sh..... 92 A.5 Blok příkazů pro nahrání všech vytvořených NuGet balíčků do cílové destinace v souboru macos_nuget_pack.sh. 93 A.6 Blok příkazů pro spuštění jednotkových testů v souboru macos_nunit_unit_test.bat...... 94 A.7 Definice dvou šablon v souboru .gitlab-ci.yml, které jsou použity pro úkoly zaměřené na kompilování zdrojo- vého kódu. Šablony jsou určeny pro použití v úkolech, které mají být prováděny na operačním systému macOS. 94

76 LISTINGS

A.8 Definice šablon a úkolů v souboru .gitlab-ci.yml urče- ných pro spouštění jednotkových testů na operačním systému Windows...... 95 A.9 Definice úkolu v souboru .gitlab-ci.yml pro tvorbu a pu- blikování NuGet oficiální verze balíčků na operačním systému macOS...... 96 A.10 Metadata projektu WebViewBridge.Android.ChromeBridge v souboru .csproj, který je součástí řešení WebViewBridge.100 A.11 Práce s příponami v souboru .csproj. Řešení převzato z [38]...... 101 A.12 Práce s příponami v souboru .csproj...... 101 A.13 Definice vlastní funkce odpovídající parametru Include- ReferencedProjects nástroje nuget u projektu WebViewBridge.Android.ChromeBridge. Řešení je převzato z [39]...... 103 A.14 Nastavení cesty k adresáři s NuGet balíčky...... 104

77 A Přílohy

A.1 Verzování

Výhody Nevýhody

Jednoduchý pracovní model Jedno centrální úložiště - jeho zajišťuje rychlé osvojení výpadek způsobí kolaps celého principů práce s SVN projektu, tzn. v době, kdy není repozitář dostupný, není možné změny v souborech verzovat Menší paměťové nároky pro Závislost na připojení uložení souborů - lokálně má k počítačové síti - bez připojení klient v pracovní kopii pouze k síti není možné úpravy jednu konkrétní verzi dat, po v souborech verzovat úpravě souboru se do centrálního úložiště nahrávají pouze rozdíly od poslední verze dat Transparentní spolupráce více Práce s SVN je poznamenána lidí - každý má do určité míry latencí sítě přehled o činnosti ostatních účastníků projektu Snadná administrace repozitáře V dřívějších verzích SVN bylo - přesná kontrola oprávnění velmi složité pracovat s větvemi jednotlivých klientů Prakticky jediný použitelný pracovní postup, který nelze efektivně použít ve všech situacích

Tabulka A.1: Výhody a nevýhody nástroje SVN

78 A. Přílohy

Výhody Nevýhody

Možnost vybírat z více Vyšší paměťové nároky než pracovních modelů dle případu u SVN, protože se na každém použití - Git lze použít klientském počítači udržuje celá například úplně stejně jako SVN historie projektu Velmi rychlé operace, protože se Distribuovaný model nástroje většina provádí lokálně Git je mnohem složitější než v souborovém systému v případě SVN Možnost plnohodnotně Špatně nastavený nebo žádný verzovat data i bez připojení specifikovaný pracovní postup k počítačové síti může vést až k úplnému zastavení pokroku při vývoji Při fatálním výpadku Používání některých operací vzdáleného repozitáře jej lze může v extrémním případě vést obnovit z kteréhokoli lokálního ke ztrátě historie projektu nebo repozitáře uživatelů dat Efektivně použitelný pro velké projekty Výborná podpora nelineárního vývoje - efektivní práce s větvemi Nelze provést změnu souboru, aniž by o tom Git nevěděl Existující grafická rozhraní pro práci - například TortoiseGit

Tabulka A.2: Výhody a nevýhody nástroje Git

A.2 Kontrola kvality kódu

79 A. Přílohy Tabulka A.3: Použitá pravidla pro kontrolu stylu psaní kódu. Detailní popis jednotlivých pravidel je dostupný v [34].

Pravidlo (kód) Popis Kategorie Akce

SA1008 Opening parenthesis must be Spacing Rules Error spaced correctly

SA1009 Closing parenthesis must be Spacing Rules Error spaced correctly

SA1010 Opening square brackets Spacing Rules Error must be spaced correctly

SA1011 Closing square brackets must Spacing Rules Error be spaced correctly

SA1012 Opening braces must be Spacing Rules Error spaced correctly

SA1013 Closing braces must be Spacing Rules Error spaced correctly

SA1014 Opening generic brackets Spacing Rules Error must be spaced correctly

SA1015 Closing generic brackets Spacing Rules Error must be spaced correctly

SA1016 Opening attribute brackets Spacing Rules Error must be spaced correctly

SA1017 Closing attribute brackets Spacing Rules Error must be spaced correctly

SA1025 Code must not contain Spacing Rules Error multiple whitespace in a row

SA1028 Code must not contain Spacing Rules Error trailing whitespace

SA1106 Code must not contain Readability Rules Error empty statements

SA1107 Code must not contain Readability Rules Error multiple statements on one line SA1110 Opening parenthesis must be Readability Rules Error on declaration line SA1111 Closing parenthesis must be Readability Rules Error on line of last parameter

SA1112 Closing parenthesis must be Readability Rules Error on line of opening parenthesis

SA1113 Comma must be on same Readability Rules Error line as previous parameter

SA1114 Parameter list must follow Readability Rules Error declaration SA1115 Parameter must follow Readability Rules Error comma SA1116 Split parameters must start Readability Rules Error on line after declaration SA1117 Parameters must be on same Readability Rules Error line or separate lines

SA1127 Generic type constraints Readability Rules Error must be on own line SA1131 Use readable conditions Readability Rules Error

SA1132 Do not combine fields Readability Rules Error

80 A. Přílohy Tabulka A.3: (Pokračování)

Pravidlo (kód) Popis Kategorie Akce

SA1133 Do not combine attributes Readability Rules Error

SA1134 Attributes must not share Readability Rules Error line SA1201 Elements must appear in the Ordering Rules Error correct order SA1202 Elements must be ordered by Ordering Rules Error access SA1203 Constants must appear Ordering Rules Error before fields SA1204 Static elements must appear Ordering Rules Error before instance elements SA1205 Partial elements must declare Ordering Rules Error access SA1206 Declaration keywords must Ordering Rules Error follow order SA1212 Property accessors must Ordering Rules Error follow order SA1213 Event accessors must follow Ordering Rules Error order SA1214 Readonly elements must Ordering Rules Error appear before non-readonly elements SA1300 Element must begin with Naming Rules Error upper case letter

SA1302 Interface names must begin Naming Rules Error with I SA1303 Const field names must Naming Rules Error begin with upper case letter

SA1304 Non-private readonly fields Naming Rules Error must begin with upper case letter SA1305 Field names must not use Naming Rules Error Hungarian notation

SA1306 Field names must begin with Naming Rules Error lower case letter SA1307 Accessible fields must begin Naming Rules Error with upper case letter

SA1308 Variable names must not be Naming Rules Error prefixed

SA1310 Field names must not contain Naming Rules Error underscore SA1311 Static readonly fields must Naming Rules Error begin with upper case letter

SA1312 Variable names must begin Naming Rules Error with lower case letter SA1313 Parameter names must begin Naming Rules Error with lower case letter SA1400 Access modifier must be Maintainability Rules Error declared SA1401 Fields must be private Maintainability Rules Error

SA1405 Debug.Assert must provide Maintainability Rules Error message text

SA1406 Debug.Fail must provide Maintainability Rules Error message text

81 A. Přílohy Tabulka A.3: (Pokračování)

Pravidlo (kód) Popis Kategorie Akce

SA1407 Arithmetic expressions must Maintainability Rules Error declare precedence

SA1408 Conditional expressions Maintainability Rules Error must declare precedence

SA1412 Store files as UTF-8 Maintainability Rules Error

SA1500 Braces for multi-line Layout Rules Error statements must not share line SA1501 Statement must not be on Layout Rules Error single line

SA1502 Element must not be on Layout Rules Error single line

SA1503 Braces must not be omitted Layout Rules Error

SA1504 All accessors must be single Layout Rules Error line or multi-line SA1505 Opening braces must not be Layout Rules Error followed by blank line

SA1507 Code must not contain Layout Rules Error multiple blank lines in a row

SA1508 Closing braces must not be Layout Rules Error preceded by blank line

SA1509 Opening braces must not be Layout Rules Error preceded by blank line

SA1510 Chained statement blocks Layout Rules Error must not be preceded by blank line SA1511 While-Do footer must not be Layout Rules Error preceded by blank line

SA1519 Braces must not be omitted Layout Rules Error from multi-line child statement SA1520 Use braces consistently Layout Rules Error

SA1633 File must have header Documentation Rules Error SA1634 File header must show Documentation Rules Error copyright

SA1635 File header must have Documentation Rules Error copyright text

SA1636 File header copyright text Documentation Rules Error must match SA1637 File header must contain file Documentation Rules Error name SA1638 File header file name Documentation Rules Error documentation must match file name SA1640 File header must have valid Documentation Rules Error company text

SA1641 File header company name Documentation Rules Error text must match SA1649 File name must match type Documentation Rules Error name SX1309 Field names must begin with Naming Rules (Alternative) Error underscore

82 A. Přílohy Tabulka A.3: (Pokračování)

Pravidlo (kód) Popis Kategorie Akce

SA1000 Keywords must be spaced Spacing Rules Warning correctly

SA1001 Commas must be spaced Spacing Rules Warning correctly

SA1002 Semicolons must be spaced Spacing Rules Warning correctly

SA1003 Symbols must be spaced Spacing Rules Warning correctly

SA1004 Documentation lines must Spacing Rules Warning begin with single space

SA1005 Single line comments must Spacing Rules Warning begin with single space

SA1006 Preprocessor keywords must Spacing Rules Warning not be preceded by space

SA1007 Operator keyword must be Spacing Rules Warning followed by space

SA1018 Nullable type symbols must Spacing Rules Warning not be preceded by space

SA1019 Member access symbols Spacing Rules Warning must be spaced correctly

SA1020 Increment decrement Spacing Rules Warning symbols must be spaced correctly

SA1021 Negative signs must be Spacing Rules Warning spaced correctly

SA1022 Positive signs must be spaced Spacing Rules Warning correctly

SA1023 Dereference and access of Spacing Rules Warning must me spaced correctly

SA1024 Colons must be spaced Spacing Rules Warning correctly

SA1026 Code must not contain space Spacing Rules Warning after new keyword in implicitly typed array allocation SA1102 Query clause should follow Readability Rules Warning previous clause

SA1103 Query clauses should be on Readability Rules Warning separate lines or all on one line SA1104 Query clause should begin Readability Rules Warning on new line when previous clause spans multiple lines

SA1105 Query clauses spanning Readability Rules Warning multiple lines should begin on own line SA1108 Block statements must not Readability Rules Warning contain embedded comments SA1118 Parameter must not span Readability Rules Warning multiple lines

SA1119 Statement must not use Readability Rules Warning unnecessary parenthesis

SA1120 Comments must contain text Readability Rules Warning

83 A. Přílohy Tabulka A.3: (Pokračování)

Pravidlo (kód) Popis Kategorie Akce

SA1121 Use built-in type alias Readability Rules Warning

SA1122 Use string empty for empty Readability Rules Warning strings

SA1123 Do not place regions within Readability Rules Warning elements SA1125 Use shorthand for nullable Readability Rules Warning types

SA1128 Constructor initializer must Readability Rules Warning be on own line SA1129 Do not use default value type Readability Rules Warning constructor SA1130 Use lambda syntax Readability Rules Warning

SA1208 System using directives must Ordering Rules Warning be placed before other using directives SA1209 Using alias directives must Ordering Rules Warning be placed after other using directives SA1210 Using directives must be Ordering Rules Warning ordered alphabetically by namespace

SA1211 Using alias directives must Ordering Rules Warning be ordered alphabetically by alias name SA1216 Using static directives must Ordering Rules Warning be placed at the correct location SA1217 Using static directives must Ordering Rules Warning be ordered alphabetically

SA1402 File may only contain Maintainability Rules Warning a single type

SA1403 File may only contain Maintainability Rules Warning a single namespace

SA1404 Code analysis suppression Maintainability Rules Warning must have justification

SA1410 Remove delegate parenthesis Maintainability Rules Warning when possible

SA1411 Attribute constructor must Maintainability Rules Warning not use unnecessary parenthesis

SA1512 Single line comments mustN Layout Rules Warning not be followed by blank line

SA1513 Closing brace must be Layout Rules Warning followed by blank line

SA1514 Element documentation Layout Rules Warning header must be preceded by blank line SA1515 Single line comment must be Layout Rules Warning preceded by blank line

SA1516 Elements must be separated Layout Rules Warning by blank line

SA1517 Code must not contain blank Layout Rules Warning lines at start of file SA1518 Use line endings correctly at Layout Rules Warning end of file

84 A. Přílohy Tabulka A.3: (Pokračování)

Pravidlo (kód) Popis Kategorie Akce

SA1604 Element documentation Documentation Rules Warning must have summary

SA1605 Partial element Documentation Rules Warning documentationM must have summary

SA1606 Element documentation Documentation Rules Warning must have summary text

SA1607 Partial element Documentation Rules Warning documentation must have summary text

SA1608 Element documentation Documentation Rules Warning must not have default summary

SA1611 Element parameters must be Documentation Rules Warning documented SA1612 Element parameter Documentation Rules Warning documentation must match element parameters

SA1613 Element parameter Documentation Rules Warning documentation must declare parameter name

SA1614 Element parameter Documentation Rules Warning documentation must have text SA1615 Element return value must Documentation Rules Warning be documented SA1616 Element return value Documentation Rules Warning documentation must have text SA1617 Void return value must not Documentation Rules Warning be documented SA1618 Generic type parameters Documentation Rules Warning must be documented SA1619 Generic type parameters Documentation Rules Warning must be documented partial class SA1620 Generic type parameter Documentation Rules Warning documentation must match type parameters

SA1621 Generic type parameter Documentation Rules Warning documentation must declare parameter name

SA1622 Generic type parameter Documentation Rules Warning documentation must have text SA1623 Property summary Documentation Rules Warning documentation must match accessors SA1624 Property summary Documentation Rules Warning documentation must omit set accessor with restricted access SA1626 Single line comments must Documentation Rules Warning not use documentation style slashes SA1627 Documentation text must not Documentation Rules Warning be empty

85 A. Přílohy Tabulka A.3: (Pokračování)

Pravidlo (kód) Popis Kategorie Akce

SA1648 Inherit doc must be used Documentation Rules Warning with inheriting class

SA1652 Enable xml documentation Documentation Rules Warning output

SA1027 Use tabs correctly Spacing Rules None

SA1100 Do not prefix calls with base Readability Rules None unless local implementation exists SA1101 Prefix local calls with this Readability Rules None

SA1124 Do not use regions Readability Rules None

SA1200 Using directives must be Ordering Rules None placed correctly

SA1207 Protected must come before Ordering Rules None internal SA1309 Field names must not begin Naming Rules None with underscore SA1600 Elements must be Documentation Rules None documented SA1601 Partial elements must be Documentation Rules None documented SA1602 Enumeration items must be Documentation Rules None documented SA1609 Property documentation Documentation Rules None must have value SA1610 Property documentation Documentation Rules None must have value text SA1625 Element documentation Documentation Rules None must not be copied and pasted

SA1639 File header must have Documentation Rules None summary

SA1642 Constructor summary Documentation Rules None documentation must begin with standard text SA1643 Destructor summary Documentation Rules None documentation must begin with standard text SA1651 Do not use placeholder Documentation Rules None elements SX1101 Do not prefix local members Readability Rules None with this (Alternative)

SX309S Static field names must begin Naming Rules (Alternative) None with underscore

86 A. Přílohy A.3 Skriptovací soubory

A.3.1 Vstupní parametry Parametry pro win10_nugets_restore.bat, macOS_nugets_restore.sh • -solution – Absolutní nebo relativní cesta k C#/.NET řešení jehož NuGet balíčky mají být obnoveny, tj. cesta k souboru s koncovkou .sln. Tento parametr musí být vždy zadán, v opačném případě se operace neprovede a na výstup je vypsána informace o chybějící hodnotě tohoto parametru.

• -msbuild – Absolutní cesta ke spouštěcímu souboru nástroje msbuild. Tento parametr je použitelný pouze pro soubor win10_nugets_restore.bat, protože v prostředí operačního systému macOS se používá skript s názvem msbuild, který je použitelný odkukoli v sys- tému.

• -source – Cesta ke zdroji, ze kterého mají být NuGet balíčky staženy.

• -destination – Cesta k adresáři, do kterého jsou NuGet balíčky ze zdroje staženy.

• -nocache – Příznak, který určuje, zda při obnovení NuGet ba- líčků pro požadovaný soubor vždy všechny NuGet balíčky stahovat z daného zdroje, anebo je možné použít cache, tj. NuGet balíčky jsou v první řadě hledány lokálně na stroji.

• -dispara – Příznak, který určuje, zda budou jednotlivé NuGet balíčky stahovány paralelně, anebo jeden po druhém.

• -verbosity – Tímto parametrem je možné nastavit množství a hloubku informací popisující dění při samotném obnovení NuGet balíčků.

• -platform – Platforma, pro kterou by mělo být dané C#/.NET řešení sestaveno. Nutné pro správné použití nástroje msbuild při obnovení NuGet balíčků.

87 A. Přílohy

• -config – Konfigurace řešení, ve které by mělo být dané C#/.NET řešení sestaveno. Nutné pro správné použití nástroje msbuild při obnovení NuGet balíčků.

Parametry pro win10_build.bat, macOS_build.sh • -project – Absolutní nebo relativní cesta k C#/.NET projektu, který má být zkompilován, tj. cesta k souboru s koncovkou .csproj. Tento parametr musí být vždy zadán, v opačném pří- padě se operace neprovede a na výstup je vypsána informace o chybějící hodnotě tohoto parametru. • -msbuild – Absolutní cesta ke spouštěcímu souboru nástroje msbuild. Tento parametr je použitelný pouze pro soubor win10_build.bat, protože v prostředí operačního systému macOS se používá skript s názvem msbuild, který je použitelný odkukoli v sys- tému. • -buildrefs – Příznak, kterým lze nastavit, zda při kompilaci da- ného projektu mají být zkompilovány i všechny jeho závislosti, tj. všechny ostatní projekty, na které se daný projekt odkazuje a používá je. • -nugetlogfile – Absolutní cesta k souboru, do kterého bude přesměrován výstup operace obnovení balíčků, pokud hodnota parametru -dorestore bude pravda, tj. před spuštěním kompilace je vyžadováno obnovení NuGet balíčků pro daný projekt. • -restorescript – Absolutní cesta ke skriptovacímu souboru ur- čeného k obnovení NuGet balíčků pro konkrétní projekt. • -dorestore – Příznak, který určuje, zda před zahájením kompilace specifikovaného projektu mají být obnoveny jeho NuGet balíčky. • -verbosity – Tímto parametrem je možné nastavit množství a hloubku informací popisující dění při samotném kompilování projektu, příp. při obnovení NuGet balíčků. • -platform – Platforma, pro kterou by měl být daný C#/.NET projekt sestaven.

88 A. Přílohy

• -config – Konfigurace, ve které by měl být daný C#/.NET projekt sestaven.

Parametry pro win10_nuget_pack.bat, macOS_nuget_pack.sh • -project – Seznam absolutních nebo relativních cest ke všem C#/.NET projektům, z nichž má být vytvořen NuGet balíček, tj. cest k souborům s koncovkou .csproj. Z každého zadaného projektu bude vytvořen jeden samostatný NuGet balíček. Tento parametr je povinný, tzn. že při spuštění skriptovacího souboru musí být vždy zadán alespoň jeden projekt, ze kterého má být vytvořen nový NuGet balíček.

• -msbuild – Absolutní cesta ke spouštěcímu souboru nástroje msbuild. Tento parametr je použitelný pouze pro soubor win10_nuget_pack.bat, protože v prostředí operačního systému macOS se používá skript s názvem msbuild, který je použitelný odkukoli v sys- tému.

• -nuget – Absolutní cesta ke spouštěcímu souboru nástroje nuget. Tento parametr je použitelný pouze pro soubor win10_nuget_pack.bat, protože v prostředí operačního systému macOS se používá skript s názvem nuget, který je použitelný odkukoli v systému.

• -apikey – Ověřovací klíč používaný v rámci operace nahrání NuGet balíčku do požadované cílové destinace.

• -source – Cesta ke zdroji, do kterého budou všechny vytvořené NuGet balíčky nahrány.

• -nugetlogfile – Absolutní cesta k souboru, do kterého bude přesměrován výstup operace obnovení balíčků.

• -restorescript – Absolutní cesta ke skriptovacímu souboru ur- čeného k obnovení NuGet balíčků pro konkrétní projekt.

• -verbosity – Tímto parametrem je možné nastavit množství a hloubku informací popisující dění při samotném procesu vytváření a nahrání NuGet balíčků na požadované místo.

89 A. Přílohy

• -platform – Platforma, pro kterou by měl být daný C#/.NET projekt sestaven. Nutné pro správné použití nástroje msbuild při tvorbě NuGet balíčků. • -config – Konfigurace, ve které by měl být daný C#/.NET projekt sestaven. Nutné pro správné použití nástroje msbuild při tvorbě NuGet balíčků. • -suffix – Přípona, která se stane součástí názvu vytvořeného NuGet balíčku. Přítomností přípony v názvu NuGet balíčku se rozlišuje, zda se jedná o oficiální či neoficiální verzi balíčku.

Parametry pro win10_nunit_unit_test.bat, macOS_nunit_unit_test.sh • -project – Seznam absolutních nebo relativních cest ke všem C#/.NET projektům, z nichž má být vytvořen NuGet balíček, tj. cest k souborům s koncovkou .csproj. Z každého zadaného projektu bude vytvořen jeden samostatný NuGet balíček. Tento parametr je povinný, tzn. že při spuštění skriptovacího souboru musí být vždy zadán alespoň jeden projekt, ze kterého má být vytvořen nový NuGet balíček. • -config – Konfigurace, ve které by měl být daný C#/.NET projekt sestaven. Nutné pro použití správných binárních souborů, při spuštění jednotkových testů. • -testresults – Adresář, do kterého mají být uloženy výsledky jednotkových testů.

A.3.2 Ukázky kódů

1 print "Restoring NuGet packages for solution '${ solutionFile}' from '${ source }' ..." 2 \textit{msbuild} /t:restore "${solutionFileAbsolute}" /p:RestorePackagesPath="${packagesDirectory}" /p: RestoreSources="${source}" /property:Platform="${ platform}" /p:Configuration="${configuration}" /p: RestoreNoCache="${noCache}" /p: RestoreDisableParallel="${disableParallel}" / verbosity:"${verbosity}"

90 A. Přílohy

3 4 # Check the operations were processed successfully and print the result 5 if [ $? -eq 0 ]; then 6 print "All NuGet packages restored successfully." 7 else 8 print "ERROR: Restoring NuGet packages for solution '${solutionFile}' failed ." 9 exit 1 10 fi 11 12 exit 0 Listing A.1: Blok příkazů pro obnovení NuGet balíčků a vyhodnocení operace ze souboru macOS_nugets_restore.sh.

1 # give the restore script file rights to be executable 2 chmod +x "${nugetRestoreScriptAbsolute}" 3 4 print "Starting NuGet restoration for solution '${ solutionFile}' in configuration '${configuration}' for platform '${platform}' -- logger output redirected to file '${solutionFolder}/${ nugetRestoreLogFile}'" 5 "${nugetRestoreScriptAbsolute}" -solution "${ solutionFileAbsolute}" -platform "${platform}" - config "${configuration}" > "${ nugetRestoreLogFileAbsolute}" 6 if [ $? -eq 0 ]; then 7 print "NuGet packages restored successfully." 8 else 9 print "ERROR: NuGet restoration failed." 10 exit 1 11 fi Listing A.2: Použití skriptu macos_nugets_restore.sh pro obnovení NuGet balíčků v souboru macos_build.sh.

1 # clean the project before build 2 print "Starting '${projectFile}' clean ... "

91 A. Přílohy

3 \textit{msbuild} "${projectFileAbsolute}" /t:Clean / consoleloggerparameters:ErrorsOnly /verbosity:${ verbosity} /p:Configuration=${configuration} / property:Platform=${platform} 4 5 if [ $? -eq 0 ]; then 6 print "Project '${projectFile}' cleaned successfully." 7 else 8 print "ERROR: Cleaning project '${projectFile}' failed ." 9 exit 1 10 fi 11 12 # Now, process the build itself 13 print "Starting build of project '${projectFile}' in configuration '${configuration}' for platform '${ platform } '..." 14 \textit{msbuild} "${projectFileAbsolute}" /t:Build / consoleloggerparameters:ErrorsOnly /p: Configuration=${configuration} /verbosity:${ verbosity} /p:RestorePackages=False /p: BuildProjectReferences=${buildReferences} / property:Platform=${platform} 15 16 # Check the operations were processed successfully and print the result 17 if [ $? -eq 0 ]; then 18 print "Project '${projectFile}' built successfully. " 19 else 20 print "ERROR: Building project '${projectFile}' failed ." 21 exit 1 22 fi 23 24 exit 0 Listing A.3: Blok příkazů pro sestavení požadovaného projektu a vyhodnocení operace v souboru macos_build.sh.

1 print "Starting NuGet packing..." 2 ciRepoFolder=$PWD

92 A. Přílohy

3 for project in "${projects[@]}"; do 4 resolve_project projectFileAbsolute projectFile "${ project }" 5 if ! [ -f "${projectFileAbsolute}" ]; then 6 print "Project '${ project }' is not present in the repository -- NUGET PACKING SKIPPED." 7 else 8 \textit{msbuild} /t:pack "${projectFileAbsolute}" /p:NoBuild= true /p:NoRestore= true /p: PackageOutputPath="${ciRepoFolder}/CreatedNuGets" /p:VersionSuffix=${suffix} /p:Configuration=${ configuration} /property:Platform="${platform}" / verbosity:${verbosity} 9 if [ $? -eq 0 ]; then 10 print "NuGet package from project '${ projectFile}' created successfully." 11 else 12 print "ERROR: NuGet package creation from project '!projectFile!' failed ." 13 exit 1 14 fi 15 fi 16 done Listing A.4: Blok příkazů pro vytvoření NuGet balíčků ze specifikovaných projektů v souboru macos_nuget_pack.sh.

1 # publish all created NuGet packages to the server 2 print "Starting NuGet packages publishing..." 3 for nupkg in `ls CreatedNuGets/*.nupkg `; do 4 nuget push "${nupkg}" -apikey "${apikey}" -source " ${ source }" 5 if [ $? -eq 0 ]; then 6 print "NuGet package '${ nupkg }' published successfully." 7 else 8 print "ERROR: Publishing of NuGet package '${ nupkg }' failed ." 9 exit 1 10 fi 11 done 12 13 exit 0

93 A. Přílohy

Listing A.5: Blok příkazů pro nahrání všech vytvořených NuGet balíčků do cílové destinace v souboru macos_nuget_pack.sh.

1 # get the current date and time 2 datetime =` date +%Y-%m-%d_%H-%M-%S` 3 # run unit tests 4 mono ${nunit} "${projectDllAbsolute}" /work:"${ testResultsDirectory}" /labels:All /result: TestResults_${datetime}.xml /out=TestsOutput.txt / config:${configuration} 5 6 # check the processed operations was succesfull or not 7 if [ $? -eq 0 ]; then 8 print "Unit tests processed successfully." 9 else 10 print "ERROR: Unit tests processing failure." 11 exit 1 12 fi 13 14 exit 0 Listing A.6: Blok příkazů pro spuštění jednotkových testů v souboru macos_nunit_unit_test.bat.

A.4 Konfigurace

A.4.1 YAML soubor

1 .macos_build: 2 before_script: 3 - chmod +x "${CI_SCRIPTS}/macos_build.sh" 4 script: 5 - '"${CI_SCRIPTS}/macos_build.sh"-project"${ PROJECT}"-config"${CONFIG}"-platform"${ PLATFORM}"-buildrefs"${BUILDREFS}" ' 6 variables: 7 BUILDREFS:"False"

94 A. Přílohy

8 PLATFORM:"AnyCPU" 9 dependencies:[] 10 artifacts: 11 when: always 12 paths: 13 - '${SOLUTION}/nugets_restore.log ' 14 - '${PROJECT_BIN} ' 15 expire_in: '4 days ' 16 tags: 17 - macOS_Sierra 18 19 .macos_develop_build: 20 extends: .macos_build 21 variables: 22 CONFIG:"Debug" 23 only: 24 - develop Listing A.7: Definice dvou šablon v souboru .gitlab-ci.yml, které jsou použity pro úkoly zaměřené na kompilování zdrojového kódu. Šablony jsou určeny pro použití v úkolech, které mají být prováděny na operačním systému macOS.

1 . win_test: 2 stage: test 3 before_script: 4 - chcp 65001 5 script: 6 - call "%CI_SCRIPTS%/win10_build.bat" -project "% PROJECT%" -config "%CONFIG%" -platform "%PLATFORM% " - buildrefs "%BUILDREFS%" 7 - '"%CI_SCRIPTS%/win10_nunit_unit_test.bat"- project"%PROJECT%"-config"%CONFIG%" ' 8 variables: 9 PLATFORM:"AnyCPU" 10 BUILDREFS:"False" 11 artifacts: 12 when: always 13 paths: 14 - '%SOLUTION%/nugets_restore.log ' 15 - '%SOLUTION%/%PROJECT%/TestResults ' 16 expire_in: '4 days ' 17 tags:

95 A. Přílohy

18 - windows10 19 20 .win_develop_test: 21 extends: .win_test 22 variables: 23 CONFIG:"Debug" 24 only: 25 - develop 26 27 test:debug:develop:web_view_bridge: 28 extends: .win_develop_test 29 dependencies: 30 - build:debug:develop:web_view_bridge 31 variables: 32 PROJECT:"${WEB_VIEW_BRIDGE_TESTS}"

Listing A.8: Definice šablon a úkolů v souboru .gitlab-ci.yml určených pro spouštění jednotkových testů na operačním systému Windows.

1 pack:release:macos: 2 stage: deploy 3 before_script: 4 - chmod +x ${CI_SCRIPTS}/macos_nuget_pack.sh 5 script: 6 - ${CI_SCRIPTS}/macos_nuget_pack.sh -project "${ WVB_WKWEBVIEW}""${WVB_WKWEBVIEW_MAC}" -source "${ NUGET_PUBLISH_SOURCE}" -config "Release" 7 dependencies: 8 - build:release:web_view_bridge 9 - build:release:helper_bridge 10 - build:release:wkwebview 11 - build:release:wkwebview_mac 12 artifacts: 13 when: always 14 paths: 15 - '${SOLUTION}/nugets_restore.log ' 16 expire_in: '4 days ' 17 only: 18 - master 19 tags: 20 - macOS_Sierra

96 A. Přílohy

Listing A.9: Definice úkolu v souboru .gitlab-ci.yml pro tvorbu a publikování NuGet oficiální verze balíčků na operačním systému macOS.

A.5 Řešení zásadních překážek

A.5.1 Vzájemná kompatibilita .NET platforem

Obrázek A.1: Přehled minimálních verzí jednotlivých .NET platforem pro podporu jednotlivých verzí rozhraní .NET Standard [35].

V tabulce na obrázku A.1 je u rozhraní .NET Framework uvedena jako minimální verze 4.6.1., která podporuje .NET Standard 2.0, avšak podpora je omezená. Microsoft doporučuje použít alespoň .NET Fra- mework 4.7.2 [35]. Ve firmě se tudíž aktuálně za účelem plné podpory knihovny .NET Standard 2.0 používají .NET platformy v následujících verzích: • .NET Framework 4.7.2

• Xamarin.iOS 11.14.0.14

• Xamarin.Mac 4.6.0.14

• Xamarin.Android 8.1

97 A. Přílohy

A.5.2 Převedení formátu Packages.config na PackageReference V této sekci budou celkově představeny dva přístupy, jak lze převést projekt používající soubor packages.config na formát PackageReference. Bez ohledu na zvolený způsob migrace je dobré před zahájením provést nastavení výchozího formátu pro práci s NuGet balíčky, které zajistí, že později při instalaci nových NuGet balíčků do projektu bude použit formát PackageReference a nebude vytvořen soubor packages.config:

1. Po spuštění programu VS2017 je potřeba přejít do nabídky Nástroje -> Manažer (správa) Nuget balíčků -> Nastavení manažera balíčků.

2. Otevře se dialogové okno, ve kterém se v levé části nachází nabídka. Z té je potřeba vybrat možnost Obecné.

3. V sekci pro správu balíčků se jako výchozí formát zvolí možnost PackageReference.

Obrázek A.2: Nastavení výchozího formátu NuGet balíčků na hodnotu PackageReference.

98 A. Přílohy

První způsob využívá integrovanou funkci programu Visual Stu- dio 2017 určenou přesně pro tento úkol. Aby bylo ale možné tuto funkci zpřístupnit a použít, je potřeba mít nainstalovaný program Visual Studio 2017 alespoň ve verzi 15.7.4. Za předpokladu, že je spuštěn program VS2017 a otevřeno řešení obsahující alespoň jeden projekt používající Packages.config, se provedou následující kroky: 1. V prohlížeči celého řešení se rozbalí projekt, u kterého má být provedena migrace. 2. V rozbalené nabídce projektu je potřeba najít soubor packages.config a na ten kliknout pravým tlačítkem myši, aby se rozbalila kon- textová nabídka. 3. Ze zobrazené nabídky se zvolí možnost Migrate from Packages.config to PackageReference. 4. Následuje analýza a výpis všeho, co bude provedeno. Po potvr- zení spuštění se provede celá migrace. Výše popsané kroky se opakují pro každý projekt, u kterého je potřeba migraci provést. Bližší informace lze najít ve zdroji [36]. Druhý způsob je oproti prvnímu pracnější, ale na konci je výsledek stejný. Tento způsob se typicky používá ve chvíli, kdy není k dispozici program Visual Studio 2017 v požadované verzi pro použití výše uvedené operace. K provedení migrace je potřeba provést následující kroky: 1. Otevře se konzole v programu Visual Studio přes nabídku Nástroje -> Manažer (správa) NuGet balíčků -> Konzole pro správu balíčků. 2. Do konzole se napíše příkaz Get-Package -ProjectName "YourPro- jectName"| Uninstall-Package -ProjectName "YourProjectName"- RemoveDependencies -Force, který ze zadaného projektu odin- staluje všechny nainstalované balíčky, tj. odstraní i soubor packages.config. 3. Nyní je potřeba instalovat všechny potřebné NuGet balíčky zpět do projektu. Protože je ale výchozí formát NuGet balíčků

99 A. Přílohy

Obrázek A.3: Zadání příkazu k odinstalování všech NuGet balíčku z konkrétního projektu v konzoli programu Visual Studio 2017.

nastaven na hodnotu PackageReference, použije tato hodnota při následující instalaci všech Nuget balíčků.

Oba dva způsoby fungují výborně a výsledek je stejný. Při řešení migrace z formátu Packages.config na PackageReference je však vhodné postupovat od projektů, které nemají žádné závislosti na jiných projektech v daném řešení a postupovat až k projektům s nejvíce závislostmi. Důvodem je, že formát PackageReference přináší využití transzitivních závislostí. Při řešení migrací tímto způsobem tak nedojde k zbytečným redundantním instalacím NuGet balíčků v projektech.

A.5.3 Přesun metadat do souboru .csproj Metadata projektu byla ze souboru AssemblyInfo.cs přesunuta pře- devším kvůli nástroji msbuild, který se používá pro práci s NuGet balíčky. Primárně byla metadata přesunuta do souboru .csproj, aby k těmto datům mohl nástroj msbuild přistupovat a číst je. Metadata jsou používaná například při tvorbě nových NuGet balíčků. Přesun metadat do souboru .csproj byl založen na dokumentaci k nástroji msbuild, která je dostupná ve zdroji [37].

1 2 AWebSys.WebViewBridge.Bridge. AndroidChrome 3 A-WebSys spol. s~r.o. 4 A-WebSys spol. s~r.o. 5 WebViewBridge.Bridge.AndroidChrome 6 2.0.1.0 7 2.0.1.0

100 A. Přílohy

8 2.0.1 9 Android bridge for communication with JavaScript. Uses Android.Webkit.WebView. 10 2018 11 Listing A.10: Metadata projektu WebViewBridge.Android.ChromeBridge v souboru .csproj, který je součástí řešení WebViewBridge.

A.5.4 Používání přípon u názvů NuGet balíčků Program msbuild neumí použít hodnotu parametru VersionSuffix ze souboru .csproj, který se pro cíl /t:pack, resp. operaci pro vytvoření NuGet balíčku, nastavuje pomocí parametru suffix. Umí však pracovat s hodnotu parametru version. Cílem úprav je zajistit, aby se při zadání parametru suffix z příka- zového řádku tato hodnota „přilepila“ za hodnotu parametru version, kterou msbuild následně vloží do názvu sestaveného NuGet balíčku, tj. do názvu souboru s koncovkou .nupkg. Současně, v případě, že přípona zadána nebude, se hodnota parametru version nezmění. Tento problém lze vyřešit přidáním následujících dvou řádku do souboru .csproj:

1 2 $(VersionSuffix) 3 2.0.1 4 $( Version)-$(VersionSuffix) 5 Listing A.11: Práce s příponami v souboru .csproj. Řešení převzato z [38].

To znamená, že výsledné řešení pro projekt WebViewBridge.Android.ChromeBridge, jehož metadata lze najít v ukázce A.10, vypadá následovně:

101 A. Přílohy

2 AWebSys.WebViewBridge.Bridge. AndroidChrome 3 A-WebSys spol. s~r.o. 4 A-WebSys spol. s~r.o. 5 WebViewBridge.Bridge.AndroidChrome 6 2.0.1.0 7 2.0.1.0 8 2.0.1 9 $(VersionSuffix) 10 $(Version)-$(VersionSuffix) 11 Android bridge for communication with JavaScript. Uses Android.Webkit.WebView. 12 2018 13 Listing A.12: Práce s příponami v souboru .csproj.

Nicméně nevýhodou tohoto řešení zůstává nutnost, přidat uve- dené řádky do všech .csproj souborů projektů, ze kterých mají být v rámci průběžné integrace vytvářeny NuGet balíčky.

A.5.5 Funkce IncludeReferencedProjects u programu dotnet

Veškeré úpravy, k dosažení požadovaného chování, je potřeba provést v souboru .csproj. Za tímto účelem je potřeba definovat nový vlastní cíl, resp. úkol, pro nástroj msbuild, který vyřeší závislosti projektu požadovaným způsobem, tj. všechny projekty, které projekt určený pro NuGet balíček používá, zahrne (jejich .dll soubory přímo do výsledného NuGet balíčku. V ukázce A.13 se jedná o cíl s názvem CopyProjectReferencesToPac- kage, který se postará o zahrnutí zkompilovaných referencovaných projektů do výsledného NuGet balíčku. Aby se tato operace provedla správně, je potřeba u každého re- ferencovaného projektu, který takto má být zpracován a zahrnut ve výsledném NuGet balíčku, přidat atribut PrivateAssets=äll¨. Bez nastavení tohoto atributu na příslušnou hodnotu se projekt do balíčku nezahrne, místo toho bude označen jako závislost balíčku, tj. pro

102 A. Přílohy správné fungování NuGet balíčku bude potřeba nainstalovat NuGet balíček z tohoto referencovaného projektu. Nakonec je potřeba vytvořený cíl i použít.

1 2 $( TargetsForTfmSpecificBuildOutput); CopyProjectReferencesToPackage 3 4 5 6 {25388510-14a8-4f1c-807b-8c7c951e1dcb} 7 WebViewBridge 8 9 10 {b2457988-f1f6-4b55-96d2-a8c9316a5dba} 11 WebViewBridge.HelperBridge 12 13 14 15 16 17 18

Listing A.13: Definice vlastní funkce odpovídající parametru IncludeReferencedProjects nástroje nuget u projektu WebViewBridge.Android.ChromeBridge. Řešení je převzato z [39].

103 A. Přílohy

A.5.6 Nastavení umístění NuGet balíčků Minimálně u všech .NET Standard 2.0 projektů je potřeba nastavit cestu k umístění NuGet balíčků na hodnotu ${SolutionFolder}/packages/. U ostatních projektů se tato cesta používá jako výchozí nastavení, ale pro lepší čitelnost může být vhodné tuto cestu nastavit explicitně u všech projektů. Toto nastavení lze provést pomocí parametru RestorePackagesPath v souboru .csproj.

1 2 $(SolutionPath)\..\packages< /RestorePackagesPath> 3 Listing A.14: Nastavení cesty k adresáři s NuGet balíčky.

104