Správa projektů pro systém GitLab Project management for GitLab
Bakal ářská práce
Studijní program: B2646 – Informační technologie Studijní obor: 1802R007 – Informační technologie Autor práce: Alina Gutsul
Vedoucí práce: Ing. Ji í Hnídek, Ph.D.
Liberec 2015/2016
4
Poděkování
Tímto bych velice ráda poděkovala vedoucímu Ing. Ji ímu Hnídkovi, Ph.D. za pomoc a cenné rady p i zpracování této práce. Mé poděkování pat i též též Ing. Igoru Kopetschkemu za věnovaný čas a ochotnou pomoc.
5
Abstrakt
Cílem práce je navrhnout a implementovat webovou aplikaci pro hromadnou správu studentských projektů systému GitLab, který je používán pro výuku informatických p edmětů na naší fakultě. Webová aplikace by měla umožňovat vytvá et projekty jednotlivým studentům a p i azovat je do p íslušných skupin na základě dat poskytnutých systémem STAG.
Klíčová slova:
GitLab, STAG, GitLab projekty, Webové služby nad IS/STAG
Abstract
The goal of this work is to implement a web application for the mass management of students projects for the GitLab system, which is used at our faculty for teaching informatics. A web application should allow creating of projects for individual students and assign them to the appropriate group, based on data provided by the system of STAG.
Key words:
GitLab, Stag, GitLab projects, IS/STAG Web Services,
6
Obsah
Seznam obrázků ... 7
Seznam zkratek ... 8
Úvod ... 9
1. Teoretická část ... 10
1.1. Služby a systémy ... 10
1.1.1. IS/STAG ... 10
1.1.2. GitLab ... 11
1.1.3. Shibboleth ... 11
1.2. Pomocné technologie ... 12
1.2.1. Ruby a Ruby on Rails ... 12
2. Verzovací systém Git a GitLab ... 13
2.1. Proč verzovací systém využívat? ... 13
2.2. Výhody systému Git ... 14
2.3. GitLab ... 16
2.4. Rešerše dostupných rozší ení pro systém GitLab ... 17
3. Návrh ... 19
3.1. Popis aplikace ... 19
3.2. Struktura aplikace ... 20
4. P istup k aplikaci ... 21
4.1. Shibboleth ... 21
4.2. STAG ... 23
5. Možnosti aplikace ... 24
6. Komunikace s Gitlabem ... 28
6.1. Konfigurace a token ... 28
6.2. Vytvo ení skupiny projektů v Gitlabu... 30
6.3. Projekty pro existující i budoucí uživatele Gitlabu ... 31
7
6.4. Další možné chyby a ošet ení ... 33
7. Získáváni dat ... 35
7.1. Webové služby nad IS/STAG ... 35
7.2. Webová služba od E-learningu ... 37
8. Testování ... 38
Závěr ... 42
Seznam použité literatury ... 43
A. Obsah p iloženého CD ... 44
B. Ukázka JSON/XML výstupu Webové služby nad IS/STAG ... 45
C. Kompletní test vytvá ení skupiny projektů ... 46
Seznam obrázků
Obrázek 1: Princip práce s verzovacím systémem 1 ... 13Obrázek 2: Princip práce s verzovacím systémem 2 ... 13
Obrázek 3: Proces uložení commitu ... 16
Obrázek 4: Návrh aplikace ... 20
Obrázek 5: P ihlašovací formulá do LIANE ... 22
Obrázek 6: Stránka s chybovou hláškou. Nedostatečná oprávnění. ... 23
Obrázek 7: Ukázka uživatelského rozhraní. Zobrazení rozvrhových akcí. ... 24
Obrázek Ř: Ukázka uživatelského rozhraní. Formulá pro vytvá ení skupiny. ... 25
Obrázek ř: Projekty v GitLabu vytvo ené pomocí rozhraní magister.nti.tul.cz ... 25
Obrázek 10: Ukázka databázové tabulky. GitlabProjects. ... 26
Obrázek 11: Ukázka uživatelského rozhraní. Indikace existujících skupin. ... 27
Obrázek 12: GitLab. Kde najít privátní token? ... 29
Obrázek 13: Ukázka uživatelského rozhraní. Kam vložit privátní token? ... 29
Obrázek 14: Algoritmus pro vytvá ení skupiny projektů ... 31
Obrázek 15: Databázové tabulky Users a TeamMembers ... 32
Obrázek 16: Stránka s chybovou hláškou. Chyba autorizace. ... 34
Obrázek 17 : Chybová hláška. Kurz není registrován v E-learningu. ... 37
Obrázek 1Ř: Screenshot testovaní aplikace (rake test). ... 41
Obrázek 1ř: Statistika aplikace (rake stats) ... 41
8
Seznam zkratek
API – Application Programming Interface Sass: Syntactically Awesome Style Sheets SOAP – Simple Object Access Protocol REST – Representational State Transfer MVC – Model-view-controller
SaaS – Software as a service
XML – Extensible Markup Language JSON – JavaScript Object Notation URL – Uniform Resource Locator SSH – Secure Shell
HTTP – Hypertext Transfer Protocol SSL – Secure Sockets Layer
TCP – Transmission Control Protocol PK – Private Key
FK – Foreign Key
9
Úvod
Verzovací systémy jsou jedním z nejdůležitějších vývojá ských nástrojů a v současné době se jejich popularita rychle zvyšuje, i když v oboru softwarového inženýrství žádnou novinkou nejsou. Pro tyto účely existuje hodně technik a různých nástrojů. Jedním z takových nástrojů je Open Source aplikace GitLab [1], kterou využíváme pro výuku i na naší univerzitě.
GitLab v TUL se většinou využívá pro výuku informatických p edmětů. Studenti verzují své domácí úlohy a semestrální práce. Vyučující je pak mohou jednoduše kontrolovat, p idávat komentá e ke kódu a také zp ístupňovat ukázkové zdrojové kódy ze cvičení či p ednášek. Aby toto bylo umožněno, vyučující je povinen vlastnoručně vytvo it repozitá a zp ístupnit ho studentům, tzn. jednoho po druhém p idat do vytvo ené skupiny. Tento proces není moc p íjemný a zabere mnoho času, proto bylo navrženo jeho automatizování.
V rámci této práce bude vytvo ena webová aplikace, která by měla sloužit pro usnadnění tvorby většího množství projektů v systému GitLab. Aplikace bude vytvo ena pro pot eby učitelů Technické univerzity v Liberci, a proto p ístup k ní budou mít pouze uživatelé, kte í jsou registrování do počítačové sítě TUL (LIANE) s rolí
„učitel“ v systému STAG. Kromě role uživatele STAG bude poskytovat i další údaje, díky čemuž uživatelé budou mít možnost vytvá et skupiny projektů podle rozvrhových akcí, tzn. pro jednotlivá cvičení nebo p ednášky.
10
1. Teoretická část
V této části jsou popsány služby a pomocné technologie, které byly použity pro vytvo ení aplikace.
1.1. Služby a systémy
Podle zadání by aplikace měla komunikovat se systémem STAG [2], který bude poskytovat data o rozvrhových akcích, a také se systémem GitLab, ve kterém se podle získaných dat budou vytvá et projekty. Autentizace uživatelů se provádí pomocí technologie Shibboleth.
1.1.1. IS/STAG
IS/STAG [3] je informační systém určený pro administraci studijní agendyvysoké školy nebo vyšší odborné školy. Systém vznikl a je vyvíjen Centrem informatizace a výpočetní techniky - St ediskem informačních systémů na Západočeské univerzitě v Plzni.
V databázi IS/STAG je uloženo mnoho různé informací, jsou to nap íklad údaje o rozvrhových akcích, studijních programech, oborech, rozvrhu místností atd. Tyto informace jsou ve STAGu vždy aktuální (nebo by měly být). P istupovat k nim lze několika způsoby a mohou je prohlížet p ihlášení a nep ihlášení uživatele (s určitými omezeními). Každý uživatel p ihlášený do systému má svoji „roli“, která určuje, ke kterým datům je povolen p ístup.
Pro prohlížení a získání dostupných údajů automatizovaně a pro integraci s dalšími počítačovými systémy slouží tzv. webové služby nad IS/STAG [4]. Jsou implementovány dva standardy webových služeb: WebServices (SOAP) a REST.
Pomocí těchto služeb je možné provádět operace čtení nebo zápisu do IS/STAG.
Výhodou využívání webových služeb je možnost výstupu v různých formátech (JSON, XML, XLS).
11
1.1.2. GitLab
GitLab [5] je Open Source webová aplikace pro správu Git repozitá ů napsaná v Ruby. Na rozdíl od podobného systému GitHub1 se více zamě uje na práci v týmu a nabízí možnost bezplatného vytvá ení neve ejných projektů (je ale možné projekt i ve ejně otev ít). Umožňuje vytvá et projekty a p i azovat do nich jednoho nebo více členů týmu s různými uživatelskými právy. Velkou výhodou GitLabu je možnost provozovat ho na vlastním hardwaru nebo v Cloudu. Pro rozsáhlé vývojá ské týmy existuje i placená Enterprice varianta GitLabu, která zahrnuje další funkce a je zamě ená p edevším na organizace s více než 100 uživateli.
P ístup a využití funkcí GitLabu z jiných aplikací umožňuje GitLab REST API [6]. Mezi p íklady API metod pat í správa uživatelů, ízení projektů, vytvá ení a vyhledáváni issues (problémy či úkoly, které je pot eba vy ešit).
1.1.3. Shibboleth
Shibboleth [7] je autentizační systém pro vzdálený p ístup k různým ve ejně nep ístupným systémům na webu, který byl vyvinut v rámci amerického projektu Internet22. Je to standardizovaný Open Source projekt, založený na principu Single-Sign-On. To znamená, že pomocí jednoho p ihlášení může uživatel využívat p ístup k více síťovým zdrojům, které tuto technologii podporují.
Systém má dvě strany komunikace: poskytovatele služeb a poskytovatele identit.
P i pokusu uživatele obdržet p ístup ke službě chráněné pomocí Shibboleth bude uživatel automatický p esměrován na stránky svého poskytovatele identit, kde může zadat p ihlašovací údaje. Po úspěšném p ihlášení se automaticky provede p esměrování na stránky požadované služby.
Webové jednotné p ihlašování na bázi Shibboleth p ináší významné zvýšení komfortu uživatelů, proto se tato technologie hojně využívá velkými organizacemi, mezi které pat i i TU v Liberci.
1 https://github.com/
2 http://www.internet2.edu/
12
1.2. Pomocné technologie
Klientská část aplikace je realizována pomocí HTML5 a SASS. Serverová část je implementovaná pomocí programovacího jazyka Ruby s využitím frameworku Ruby on Rails.
1.2.1. Ruby a Ruby on Rails
Ruby [11] je dynamický, reflexní, objektově-orientovaný a Open Source programovací jazyk, navržený a vyvinutý japonským programátorem Yukihiro Matsumotem v průběhu ř0. let. Je vytvo en spojením částí jazyků, jako Perl, Smalltalk, Eifel, Ada, Lisp, a je zamě en na jednoduchost a produktivitu. Podobně jako ve většině programovacích jazyků lze v Ruby použít širokou škálu knihoven t etích stran, které jsou většinou realizované jako gem.
Ruby on Rails [12] je framework pro rychlé vytvá ení webových aplikací. Je založen na návrhovém vzoru Model-View-Controller (MVC). Používá abstraktní vrstvu pro práci s databází (Active Record), scaffolding (generátory kódu) a má zabudovanou podporu pro automatizované testování všech vrstev aplikace. Publikoval jej v roce 2004 dánský programátor David Heinemeier Hansson.
13
2. Verzovací systém Git a GitLab
V dnešní době existuje mnoho různých verzovacíchsystémů, mezi něž pat í Apache Subversion, Bazaar, Darcs, Mercurial atd. Jedním z nejrozší enějších je distribuovaný systém správy verzí Git [13], který byl vytvo en Linusem Torvaldsem pro spravování vývoje jádra Linuxu. Dnes je používán mnoha známými projekty, nap . Chromium, jQuery, PHP, MediaWiki, Ruby on Rails atd.
2.1. Proč verzovací systém využívat?
Verzovací systém slouží jako úložiště zdrojových kódů a důležitých souborů.
Umožňuje uchování verzí projektů a spolupráci více lidí na jednom projektu.
Uchováni historie - velice užitečná funkce verzovacího systému, která umožní získat část kódu, který jsme smazali, nebo v p ípadě nefunkčnosti projektu se vrátit k poslední funkční verzi.
Týmová spolupráce – jeden projekt může být sdílen pro více lidí, kte í na něm mohou pracovat zároveň, bez pot eby vzájemného kopírováni či p episováni souborů na sdíleném disku.
Práce ve více větvích – možnost udržovat jeden projekt ve více větvích.
Na následujících obrázcích je znázorněn princip práce s verzovacím systémem.
Data jsou uložená na společném serveru, na který jednotliví členové týmu odesílají své upravené soubory a stahují si změny. S jedním úložištěm dat může pracovat více klientů. Když si ale několik lidí stáhne ze serveru stejnou verzi projektu a budou na ní pracovat, tak bez problému udělá commit pouze první. Ostatní členové týmů budou muset nejprve vy ešit konflikty mezi verzemi, tzn. stáhnout si poslední commit a pak p idat své změny.
Obrázek 1: Princip práce s verzovacím systémem 1 Obrázek 2: Princip práce s verzovacím systémem 2
14
2.2. Výhody systému Git
Distribuovaný charakter systému Git [13] p ináší další výhody, jako nap .:
Lokální operace – většina operací v systému Git vyžaduje ke své činnosti pouze lokální soubory a nejsou pot eba informace z jiných počítačů v síti, protože historie projektu je uložená p ímo na lokálním disku. Toto způsobuje okamžité vykonání většiny operací.
Více scénářů práce – Git umožňuje velkou flexibilitu p i spolupráci vývojá ů na projektech a nabízí další pracovní postupy: centralizovaný pracovní postup, pracovní postup s integračním manažerem, pracovní postup s diktátorem a poručíky.
Vytvo it projekt v systému Git lze dvěma základními způsoby:
Inicializovat nový Git repozitá a importovat do něj existující projekt.
V libovolném adresá i můžeme vytvo it nový Git repozitá prostým p íkazem git init. Tento p íkaz vytvo í tzv. kostru repozitá e Git. Dalším krokem je p idání URL pro vzdálený p ístup k repozitá i na serveru pomocí p íkazu git remote add.
git init
git remote add origin https://gitlab.com/user/repo.git
Naklonovat již existující Git repozitá .
Pro vytvo ení kopie existujícího repozitá e Git použijeme p íkaz git clone, pomocí kterého získáme kopii témě všech dat ze serveru, tzn. všechny verze všech souborů.
Pro p enos dat nabízí Git adu různých protokolů. Níže je každý z nich popsán s ukázkou využití (klonování repozitá e):
15
Protokol SSH
SSH je nejčastěji používaným síťovým protokolem pro autentizovaný p ístup do repozitá e pomocí SSH klíče. Veškerý p enos dat je bezpečný a šifrovaný. P ed p enosem jsou data upravena do co nejkompaktnější podoby, proto je to zároveň i výkonný způsob. Navíc protokol umožňuje jednoduché čtení a zápis. Jiné protokoly jsou většinou určené pouze pro čtení.
git clone git@server:user/repo.git
Protokol Git:
Je to speciální démon, který je distribuován spolu se systémem Git. Poskytuje podobnou službu jako protokol SSH, ale bez autentizace. To znamená, že repozitá Git je dostupný pro všechny. Pro p enos dat používá démon Git stejný mechanizmus jako SSH, na rozdíl od něj se ale nezpomaluje šifrováním a autentizací. Aby byl repozitá zp ístupněn protokolem Git, musíme vytvo it soubor git-daemon-export-ok.
git clone git://server/user/repo.git
Protokol http(s):
Velkou výhodou protokolu http/https je jednoduché nastavení. Stačí pouze umístit Git repozitá do ko enového adresá e HTTP a nastavit p íslušný zásuvný modul post-update. Pro p ístup do repozitá e bude muset uživatel prokázat svou identitu pomocí uživatelského jména a hesla. Nevýhodou tohoto protokolu je poměrně nízká výkonnost.
git clone https://server/user/repo.git
Git má jednoduchou a nekomplikovanou organizaci souboru a umožňuje nastavit soubory či složky, které by se verzovat neměly. eší se to pomocí jediného souboru .gitignore, který je součástí repozitá e a obsahuje relativní adresy k ignorovanému obsahu.
16
Proces uložení revize (commitu) Git rozděluje do dvou kroků: na p ípravu obsahu k uložení do revize pomocí indexování a na samotné uložení revize. Můžeme si p ipravovat určitý obsah, který chceme do repozitá e commitnout pomocí p íkazů typu
git add public/*.js. Takový p ístup umožňuje zaznamenávat do repozitá e atomické a smysluplné revize a nemíchat dohromady nesouvisející změny.
Obrázek 3: Proces uložení commitu
2.3. GitLab
GitLab [5] je efektivní nástroj pro správu úložiště Git s p íjemným rozhraním, nabízející funkce wiki a sledování problémů. Výhodou je také textový editor, který umožňuje vytvá et a posílat commity p ímo z webového rozhraní.
GitLab existuje ve dvou podobách:
1. SAAS – webové stránky s otev enou registrací.3
2. Individuální ešení – GitLab Community Edition4, které je možné nainstalovat na vlastní server a nastavit podle sebe.
Tento způsob byl využit vedoucím práce pro nainstalování testovací verze GitLabu, která je dostupná na adrese gitlab.nti.tul.cz. Tato verze GitLabu se používala pro testování aplikace vytvá ené v průběhu této bakalá ské práce.
GitLab umožňuje vytvá et privátní či ve ejné projekty a p i azovat do nich členy týmu s různými p ístupovými právy. Uživatelská p ístupová práva v GitLabu jsou definována pomocí čty rolí:
Guest – vidí základní informace o projektu (p ílohy, kousky kódu (snippets), úkoly (issues), wiki).
3 https://gitlab.com/users/sign_in
4 https://gitlab.com/gitlab-org/gitlab-ce
17
Reporter – má navíc možnost číst z repozitá e a může si projekt stáhnout.
Developer – má možnost číst a psát do repozitá e.
Master – může p idávat nové členy projektu, měnit základní nastavení.
Owner – má všechna oprávnění.
V rámci projektů na Gitlabu je možné vytvá et issues. Jsou to věci, které by se měly v projektu ještě vy ešit nebo zlepšit. K vytvo enému issue lze p i adit uživatele, štítky a popis. Také mu můžeme nastavit datum, do kdy by měl být splněn (pomocí miestones) a p idávat komentá e.
2.4. Rešerše dostupných rozšíření pro systém GitLab
GitLab je známá platforma pro kodéry a programátory po celém světě. Proto je samoz ejmostí, že se stále vyvíjí nějaká nová rozší ení. V této podkapitole popíšu některé z nich.
P i hledání zajímavých rozší ení pro GitLab jsem došla k výsledku, že většina z nich se zamě uje na zlepšení zpracování issue. Což dává smysl, protože když se na projektu pracuje v týmu, tak je velmi důležité správně rozdělit úkoly (issues) mezi všechny členy skupiny a pak mít o tom nějaký p ehled. Níže uvádím p íklady rozší ení, který to umožňují:
GitLab Kanban Board 5– volná open source aplikace pro vizualizaci toku práce s Gitlab issues. Tato aplikace je postavena na základě využití GitLab API, tzn. že issues, které se v aplikaci zobrazují, jsou z databáze GitLabu, a proto není pot eba synchronizovat účty. Kanban board dává svému týmu jasné pochopení toho, kdo na čem pracuje a v jakém stavu se určité issue nachází. Aplikace se instaluje na vlastní server, online verze zatím není.
Hubstaff’s Gitlab Time Tracking 6– placené rozší ení pro skupinovou práci v GitLabu, se kterým mají uživatele možnost sledovat čas, který stráví na vy ešení jednotlivých issues. Aplikace monitoruje všechny členy skupiny a na základě získaných dat zobrazuje různé statistiky, s kterými uživatelé mohou získat jasnou p edstavu o produktivitě práce členů týmu.
5 http://kanban.leanlabs.io/
6 http://blog.hubstaff.com/gitlab-time-tracking/
18
Skoro každá aplikace už má mobilní verzí. GitLab také není výjimkou a má spoustu různých mobilních rozší ení pro všechny platformy. Ve většině z nich nejde udělat vše, co umožní webová aplikace, ale pro p ehled a správu projektů či issues to plně stačí.
LabCoat for GitLab – open souce mobilní aplikace pro android umožňující správu projektů, vytvá ení issues a dokonce i potvrzení merge requestů.
Trident – GitLab a GitHub klient pro IOS s p íjemným prost edím a funkcí nightmode. Aplikace je zamě ená hlavně na sledování issues. Umožňuje je prohlížet, editovat, komentovat a p idávat nové.
Branches – další aplikace pro správu issues na IOS. S její pomocí se dají měnit, p idávat a vyhledávat issues a také prohlížet větve a commity.
GitLab mobile App – mobilní aplikace pro android, která nabízí možnosti prohlížení commitů, otevíraní a editovaní issues, správu týmů.
19
3. Návrh
Jak již bylo zmíněno, systém GitLab se používá pro výuku i na naší fakultě [1].
Pro studenty jsou vytvo eny projekty, do kterých nahrávají své vy ešené úlohy. Tyto projekty jsou většinou p i azené do skupin podle cvičení. Skupinu s p íslušnými projekty musí vytvo it vyučující ručně, protože GitLab nenabízí žádný způsob, jak tento proces zjednodušit.
Tato kapitola popisuje návrh ešení hromadného vytvá ení projektů a vlastnosti aplikace, která tento proces zjednoduší a automatizuje.
3.1. Popis aplikace
Navrhovaná aplikace má poskytovat jednoduché a rychlé ešení pro hromadné vytvo ení Git repozitá ů pro studenty v systému GitLab. P ístup k aplikaci budou mít pouze učitelé Technické univerzity v Liberci, což se zajistí pomocí technologie Shibboleth. Po úspěšném p ihlášení se uživateli zobrazí seznam jeho p edmětů ze STAGu. Dále by uživatel měl zvolit určitý p edmět, čímž se dostane ke svým rozvrhovým akcím. Učitel si bude moci vybrat, chce-li vytvo it skupinu na GitLabu pro všechny studenty z p ednášky, nebo pouze pro ty, kte í jsou na určitém cvičení.
Posledním krokem bude vyplnění formulá e, do kterého se musí zadat jméno a popis požadované skupiny. Aplikace nebude umožňovat p idávat do skupiny studenty, kte í k rozvrhové akci nepat í. Po odeslání formulá e by se do několika vte in měla vytvo it na GitLabu skupina projektů pro studenty. Každému studentovi budou p idělena p ístupová práva pouze k projektu, který byl pro něj vytvo en.
20
3.2. Struktura aplikace
Pro dosažení cíle by vytvo ená aplikace měla komunikovat se systémy STAG a GitLab. Proto se dá íct, že aplikace bude dělena do dvou základních částí.
Obrázek 4: Návrh aplikace
První část aplikace má za úkol navázat spojení se systémem STAG a podle toho, jaký uživatel je do aplikace p ihlášen, získat pot ebná data (rozvrhové akce). Provádět se to bude pomocí několika dotazů na Webové služby nad IS/STAG [4]. Některé z těchto služeb jsou omezené uživatelskými p ístupovými právy, proto se musí vy ešit problém p ihlašování do STAGu .
Druhá část aplikace se zamě uje na komunikaci se systémem GitLab. Podle zvoleného p edmětu a zadaných parametrů (název, popis) bude v GitLabu vytvo ena skupina, do níž se p idají projekty pro jednotlivé studenty z tohoto p edmětu. Dále bude každému studentovi p idělen p ístup k projektu, který byl pro něj vytvo en.
Komunikace s GitLabem bude probíhat prost ednictvím posílání REST dotazů na určité funkce GitLab API [6].
21
4. Přistup k aplikaci
Vytvo ená aplikace bude umístěna na adrese https://magister.nti.tul.cz a p ístup k ní budou mít pouze učitelé naší univerzity.
Vzhledem k tomu, že se aplikace vytvá í pro TU v Liberci, dohodli jsme se s vedoucím, že autentizace uživatelů bude probíhat pomocí technologie Shibboleth, která je široce používaná na naší univerzitě. Jelikož je Shibboleth založen na principu Single-Sign-On, odpadne nutnost opakovaného p ihlášení do GitLabu, který také využívá autentizaci touto technologií. Pro další ově ení role uživatele se používají webové služby nad IS/STAG.
4.1. Shibboleth
Konfigurace
Pro zprovoznění Shibboleth autentizace pot ebujeme správně nakonfigurovaný HTTP server Apache s podporou SSL a nainstalovaný Shibboleth SP 2.5.x [10].
Požadavky na konfiguraci [9]:
Do webového serveru je t eba nainstalovat platný SSL certifikát podepsaný důvěryhodnou certifikační autoritou.
Pro povolení Shibboleth autentizace musí byt na firewallu povoleny odchozí TCP pakety na určitém portu.
Také je pot eba synchronizovat systémový čas na serveru s externím NPM serverem.
Hlavní konfigurace Shibboleth jsou umístěna v souboru shibboleth2.xml. Níže jsou uvedeny změny, které se v tomto souboru mají provést:
Vyplnit jméno serveru/aplikace (entityID).
<ApplicationDefaults entityID="https://magister.nti.tul.cz/shibboleth"…/>
Nastavit dobu session a timeout.
<Sessions lifetime="28800" timeout="3600" …/>
22
Nastavit poskytovatele identity (IdP).
<MetadataProvider uri="https://shibbo.tul.cz/metadata/tul-metadata.xml"/>
Zkontrolovat cestu k OpenSSL certifikátům /etc/ssl.
Přihlášení
Když uživatel projeví zájem o p ístup k aplikaci, bude automaticky p esměrován na stránky sítě LIANE, kde může potvrdit svou identitu.
Obrázek 5: Přihlašovací formulář do LIANE
Po úspěšném p ihlášení poskytuje Shibboleth informace o uživateli, které se pak mohou využívat aplikací.
Tyto údaje jsou dostupné na adrese:
https://magister.nti.tul.cz/Shibboleth.sso/Status
Pro zp ístupnění atributů z Shibboleth session ve své aplikaci jsem na doporučení mého vedoucího použila takzvaný OmniAuthShibboleth Strategy [14]. Je to gem pro rails aplikaci, poskytující proměnné prost edí, které obsahují uživatelské atributy (nap íklad mail, phone, eppn, name). Pro naši aplikaci je nejdůležitějším atributem „eppn“. Je to identifikátor uživatelů (v p ípadě sítě LIANE je to uživatelský e-mail).
23
4.2. STAG
Kvůli tomu, že aplikace má být p ístupná pouze pro učitele, tak dalším krokem autentizace musí být ově ování role uživatele podle systému STAG. Pro tyto účely se dá využít webové služby nad IS/STAG [4].
Každý učitel má ve Stagu p iděleno ID (ucitIdno). Proto ově ení můžeme provést pomocí služby:
users/getUcitIdnoByStagLogin?externalLogin=#{login}
která vrátí ucitIdno na základě externího uživatelského jména učitele. Externí jméno uživatele zjistíme parsováním uživatelského e-mailu, který se po p ihlášení pomocí Shibboleth bude nacházet v proměnné prost edí „eppn“:
login = request.env["eppn"].split ('@').first
Pokud ve výstupu od služby dostaneme ID, můžeme ho uložit do session a otev ít uživateli p ístup k aplikaci. V jiném p ípadě bude uživatel p esměrován na stránku s chybovou hláškou:
Obrázek 6: Stránka s chybovou hláškou. Nedostatečná oprávnění.
24
5. Možnosti aplikace
Aplikace nabízí jednoduché prost edí pro rychlé vytvá ení skupin projektů v Gitlabu s automatickým p ednastavením členů skupiny podle rozvrhu uživatele ve STAGu.
Po úspěšném p ihlášení do aplikace se uživateli zobrazí seznam p edmětů, které v akademickém roce učí. Položky seznamu jsou proklikatelné a vedou na rozvrhové akce p edmětů:
Obrázek 7: Ukázka uživatelského rozhraní. Zobrazení rozvrhových akcí.
Z bezpečnostních důvodů STAG omezuje čtení některých dat (viz Webové služby nad IS/STAG), a proto se rozvrhové akce k p edmětům vypisují podle kurzu v E-learningu. Tím pádem uživatelé musí do elearningu zaregistrovat p edměty, pro které by chtěli aplikaci pro správu účtu využívat, což není obtížné.
Pokud je všechno v po ádku, uživatel si může zvolit určité cvičení či p ednášku, podle které by chtěl vytvo it skupinu projektu na GitLab. Posledním krokem je vyplnění formulá e, ve kterém se zadává název a popis skupiny, p ípona názvu projektu (část názvu za jménem studenta, defaultně se nastavuje podle zkratky p edmětu), a také p ípadná filtrace studentů pomocí checkboxů.
25
Obrázek 8: Ukázka uživatelského rozhraní. Formulář pro vytváření skupiny.
Po stisknutí tlačítka odeslat se podle zadaných údajů vytvo í skupina a p idávají se do ní projekty. Podrobněji bude tento proces popsán v kapitole o Gitlabu (Vytvo ení skupiny projektů v Gitlabu).
Na následujícím obrázku je vidět, že pro vybrané studenti byly v GitLabu vytvo ené projekty ve skupině s názvem „New Group“:
Obrázek 9: Projekty v GitLabu vytvořené pomocí rozhraní magister.nti.tul.cz
26 Vytvořené skupiny
Pro lepší p ehlednost a orientaci uživatelů v již vytvo ených skupinách bylo rozhodnuto tyto údaje ukládat. Z toho důvodu byla do databáze p idána tabulka GitlabProjects:
Obrázek 10: Ukázka databázové tabulky. GitlabProjects.
Po úspěšném vytvo ení skupiny se do této tabulky zapíše id skupiny z GitLabu (id_gitlab_group) a id vybrané rozvrhové akce z E-learningu (id_course). Tyto údaje poté umožní uživateli ukázat, pro jaké rozvrhové akce už existují skupiny v GitLabu.
P i výpisu rozvrhových akcí se zkontroluje, jestli pro ně existují v tabulce GitlabProjects nějaké záznamy. V dalším kroku se otestuje, jestli skupiny z tabulky existují i v GitLabu (podle id_gitlab_group). Pokud ne, tak se tento záznam z tabulky vymaže.
begin
names = Gitlab.group(course['id_gitlab_group']).name rescue Gitlab::Error::NotFound => not_found
GitlabProject.delete(course.id) end
Výhodou je, že se tyto informace ukážou všem uživatelům, kte í mají stejné p edměty. Proto nedojde k tomu, že by dva učitelé nechtěně vytvo ili skupiny projektů pro stejnou rozvrhovou akci.
27
Obrázek 11: Ukázka uživatelského rozhraní. Indikace existujících skupin.
28
6. Komunikace s Gitlabem
Komunikace s GitLabem a p ístup k jeho funkcionalitě se provádí prost ednictvím dotazováni na REST API. S jeho pomocí se dají jednoduše využívat témě všechny funkce, které jsou ve webovém rozhraní GitLabu. Všechny API dotazy vyžadují autentizaci, proto klient vždy musí posílat privátní GitLab token v hlavičce nebo jako parametr. Také se v každém dotazu musí poslat GitLab URL a verze API.
Pomocí těchto údajů se na serveru gitlab.nti.tul.cz vytvo í GitLab klient. Výstupem je JSON, formovaný podle zadaných parametrů.
P íklad API dotazu:
GET https://gitlab.example.com/api/v3/projects?private_token=9koXpvBs5tK
P íklad API dotazu s využitím cURL s autentizací p es hlavičku:
curl --header "TOKEN: Un0jI" https://gitlab.example.com/api/v3/projects
6.1. Konfigurace a token
Pro komunikaci s GitLab API jsem použila ruby gem gitlab [15]. Tento balíček maximálně zjednodušuje dotazy a hlavně autentizaci. Už není pot eba pokaždé posílat údaje, stačí jednou provést konfiguraci:
Gitlab.configure do |config|
config.endpoint = "https://gitlab.nti.tul.cz/api/v3"
config.private_token = user.token end
Aby bylo možné provést autentizaci a tím vytvo it GitGab klienta, musí každý uživatel svůj token ručně uložit na magister.nti.tul.cz.
29 Kde najít privátní token a jak ho uložit?
P ihlásit se do účtu na gitlab.nti.tul.cz
Vybrat v menu Profile settings
Vybrat v menu Account
Zkopírovat privátní token
Obrázek 12: GitLab. Kde najít privátní token?
P ejít na stránky magister.nti.tul.cz do záložky Nastavení
Vložit token do pole a uložit
Obrázek 13: Ukázka uživatelského rozhraní. Kam vložit privátní token?
30
Po úspěšném uložení tokenu bude možné z aplikace navázat spojení s Gitlabem a to znamená, že se uživateli odblokuje možnost vytvá et skupiny.
6.2. Vytvoření skupiny projektů v Gitlabu
Pro vytvá ení skupin byl vytvo en modul s funkcemi, které k tomuto účelu budeme pot ebovat. Každá funkce má jeden úkol (vytvá ení skupiny, vytvá ení projektu atd.), což zjednoduší testování a umožní p ípadné další využití či rozší ení funkcionality aplikace.
Postup vytvá ení skupiny projektů je rozdělen do několika části:
1. Vytvořit a uložit skupinu
group = Gitlab.create_group(name, path, description)
2. Vytvořit projekt pro každého studenta podle jeho jména a přípony předmětu. Do parametru projektů se p idává ID skupiny, vytvo ené v minulém kroku
project = Gitlab.create_project(name,description,group.id,namespace.id)
3. Přidání členů skupiny. Po vytvo ení projektu následuje pokus o p idání studenta do tohoto projektu. Student se p idává s úrovní oprávnění „Developer“, tzn.
může provádět akce v rámci svého projektu. P idat člena skupiny je možné pouze v p ípadě, že v GitLabu existuje uživatel s požadovaným uživatelským jménem. Tuto problematiku budu vysvětlovat v další podkapitole (Projekty pro existující i budoucí uživatele GitLabu).
Gitlab.add_team_member(project.id, user.id, permissions)
31
Obrázek 14: Algoritmus pro vytváření skupiny projektů
Skupiny a projekty budou z pohledu studenta vytvo ené stejně jako pomocí webového rozhraní GitLab. Uživatelé dostanou e-mail, že jim byl p idělen p ístup k projektu v určité skupině s oprávněním „Developer“, a budou ho moci využívat.
6.3. Projekty pro existující i budoucí uživatele GitLabu
P ístup do GitLabu je také nastaven pomocí technologie Shibboleth a účty pro uživatele se vytvá ejí po prvním p ihlášení. Tato technologie má své výhody a nevýhody pro vytvá enou aplikaci.
Registrace účtu pomocí Shibboleth zajišťuje, že uživatelské jméno každého uživatele bude odpovídat jeho lianovskému loginu, který můžeme zjistit pomocí webových služeb nad STAG nebo, jak to funguje v našem p ípadě, pomocí REST API od E-learningu. Tím pádem můžeme vyhledávat studenty v GitLabu podle uživatelského jména.
user = Gitlab.users(username: "alina.gutsul")
V p ípadě, že uživatel s takovým jménem je v GitLabu registrován, jsme schopni jej p idat do už vytvo eného projektu. V jiném p ípadě, tzn. uživatel se ještě nep ihlašoval a nemá vytvo ený účet, by mohlo v aplikaci dojít k chybě. Ty studenty,
32
kte í se zaregistrovali do GitLabu později, by učitel musel p idat do určitých projektů ručně, což by bylo nep íjemné.
Z tohoto důvodu jsem se rozhodla, že nejlepším ešením problému bude ukládat neexistující uživatele a v pravidelných intervalech je zkoušet p idávat do skupiny bez pot eby nutit učitele provádět jakékoliv akce.
Pro opakované p idávání studenta do určitého projektu pot ebujeme ukládat jeho uživatelské jméno, ID jeho projektu a token učitele, od jehož jména se tyto akce provádějí. Z tohoto důvodu byla v databázi vytvo ena další tabulka TeamMembers. P i dalším zpracování těchto údajů by bylo rychlejší, kdyby v tabulce byl uložen p ímo token učitele (jako String). Takový p ístup by ale mohl způsobit chybu v p ípadě, že si učitel v GitLabu nastaví nový token. V tabulce by byl uložen starý již neplatný token, což by p i dotazu na GitLab API způsobilo chybu špatné autentizace. Jako ešení tohoto problému bylo zvoleno spojení tabulek Users a TeamMembers pomocí FK user_id, který reprezentuje ID učitele v aplikaci. Pomocí tohoto ID získáme p íslušný token, který byl uživatelem uložen naposledy.
Obrázek 15: Databázové tabulky Users a TeamMembers
Dalším krokem bylo napsání skriptu, který se bude pravidelně spouštět pomocí Cronu. Jeho úkolem bude ově it, jestli v Gitlabu už byly vytvo eny nové účty pro studenty, jejichž uživatelská jména jsou v tabulce TeamMembers, a p i úspěchu je p idat do projektů. Z důvodu, že skript je samostatný a nachází se mimo aplikaci, se musejí globálně doinstalovat gemy, které jsou skriptem využívány (mysql a gitlab).
33 Popis akcí, které se vykonávají ve scriptu:
Stažení a formátováni dat z tabulky Users do pole pro další jednodušší vyhledávání tokenu uživatele:
tokens[id_user] = token
Stažení a testovaní dat z tabulky TeamMembers. Pro každou staženou položku se musí otestovat:
Je-li možné zjistit token učitele, od jehož jména se vytvo il projekt pro studenta.
Je-li student už v GitLabu registrován.
V p ípadě, že oba testy proběhly v po ádku, bude student p idán do svého projektu a položka z tabulky s jeho jménem se smaže.
Po konzultaci s vedoucím bylo vy ešeno, že se tyto akce budou provádět pomocí démona Cron. Je to systémový nástroj pro Linux/Unix, který spouští různé programy v p edem definovanou dobu. S jeho pomocí bylo nastaveno, aby se skript spouštěl každý den v 4:30 bez vědomí uživatelů aplikace. Proto p i vytvá ení skupiny projektu není pot eba na nic myslet. D íve nebo později budou projekty vytvo eny pro všechny studenty.
6.4. Další možné chyby a ošetření
V GitLab API je stanovená sada stavových kódů, které se vracejí v p ípadě, že došlo k nějaké chybě. S jejich pomocí je uživatel schopen získat vhled do toho, co se v programu pokazilo.
Níže jsou uvedené stavové kódy a vysvětlení chyb, které by v aplikaci mohly nastat:
401 Unauthorized:
K této chybě může dojit v p ípadě, že uživatel má v aplikaci neplatný privátní token nebo ho zatím neuložil.
400 Bad Request:
Tato chyba nastane, když se uživatel bude pokoušet o vytvo ení skupiny s názvem už existující skupiny, což se v GitLabu nedovoluje.
34
Dále uvádím p íklad, jak se ošet ují tyto chyby v aplikaci pomocí konstrukce begin-rescue:
begin
create_group_with_projects(name, description, project_key, users) rescue Gitlab::Error::Unauthorized => unauthorized
flash[:error] = "Zkontrolujte prosím privátní token."
redirect_to settings_url end
V p ípadě chyby bude uživatel p esměrován na p íslušnou stránku s odpovídající hláškou:
Obrázek 16: Stránka s chybovou hláškou. Chyba autorizace.
35
7. Získáváni dat
Z důvodu, že vytvo ená aplikace je cílena na umožnění vytvá ení projektů v GitLabu podle rozvrhových akcí, musí využívat jiné systémy, které můžou tyto informace poskytovat. Podle původního plánu měl být hlavním zdrojem dat systém STAG. V průběhu vývoje aplikace jsem se setkala s komplikacemi, jejichž problematiku a ešení popíšu v této kapitole.
7.1. Webové služby nad IS/STAG
Webové služby nad IS/STAG [4] poskytují mnoho různých služeb. Každá služba provádí nějakou určenou operaci a podle zadaných parametrů nám může vrátit požadované informace.
Pro práci s těmito službami jsem zvolila využití REST standardu. Tento standard je orientován na data – data mají svoji URL adresu. To znamená, že pro volání určité služby stačí vědět p íslušnou URL a na ní webové služby poskytnou požadovaná data ve formátu XML (defaultně), JSON, XLS (viz p íloha B).
P iklad REST adresy pro zjištění ucitIdno (v aplikaci se využívá pro autentizaci učitele):
stag-ws.tul.cz/ws/services/rest/users/getUcitIdnoByExternalLogin?login=login
Jednotlivé části adresy:
stag-ws.tul.cz/ws/services/ - základní URL webových služeb
rest/users/ - adresa konkrétní služby
getUcitIdnoByExternalLogin – název metody
?login=login – parametry pro tuto metodu
Také se k URL p idává ještě jeden volitelný parametr, který určuje požadovaný formát výstupu. V aplikaci používám tento parametr pro získání výstupu ve formátu JSON „outputFormat=JSON“.
36
P íklad nastavení REST dotazu na Webové služby v Ruby:
API_URL ='stag-ws.tul.cz'
uri='#{API_URL}/ws/services/rest/rozvrhy/getRozvrhByUcitel?ucitIdno=#{idno}' rest_resource = RestClient::Resource.new(uri)
courses = rest_resource.get courses = JSON.parse(courses)
Zde jsou p íklady dalších webových služeb, které jsem v aplikaci využívala:
Pro získání rozvrhu učitele (podle ucitIdno):
stag-ws.tul.cz/ws/services/rest/rozvrhy/getRozvrhByUcitel?ucitIdno=62587
Pro získání rozvrhu p edmětu:
API_URL/ws/services/rest/rozvrhy/getRozvrhByPredmet?katedra=NTI&zkratka=PJP
Posledním krokem p i získání dat v aplikaci by měl být výpis seznamu studentů ve vybraném p edmětu. Pro tento účel se nabízí další webová služba:
API_URL/ws/services/rest/student/getStudentiByPredmet
Z důvodu bezpečnosti tato služba už má omezení a můžou ji použít pouze p ihlášené uživatele. Pro vy ešení této nečekané komplikace jsem měla na rozmyšlení 2 možnosti:
1. Nutit uživatele aplikace přihlašovat se i do STAGu.
P ihlášení do STAGu má časový limit (30 minut), proto zaprvé by obnovování p ihlášení bylo pro uživatele aplikace nep íjemné a zadruhé kvůli vypršení časového limitu v nevhodnou chvíli by mohlo v aplikaci dojít k chybě.
2. Vložit do kódu údaje od vlastního účtu a provádět přihlašovaní na pozadí.
Vždy by někdo musel zapůjčit k exploataci své p ihlašovací údaje.
Po zhodnocení jsem došla k výsledku, že žádná z těchto možností pro aplikaci nevyhovuje, a proto se musel hledat jiný způsob vy ešení problému.
37
7.2. Webová služba od E-learningu
Dotazy ohledně STAGu a webových služeb byly konzultovány s Ing. Igorem Kopetschkem, který mi pomohl pokročit dále. Vytvo il pro aplikaci další REST webovou službu od E-learningu.
Nová REST webová služba se nachází na URL:
https://elearning.tul.cz/webservice/rest/server.php, a vrací rozvrhové akce podle zadaných parametrů:
shortname – krátký název p edmětu (nap . NTI/ADA)
academic_year – akademický rok (nap . 2015 pro rok 2015/2016)
Výstupem je JSON pole, které obsahuje rozvrhové akce p edmětu. Každá položka tohoto pole obsahuje:
groupname – název rozvrhové akce (Cvičení Čtvrtek Každý týden 12:30-14:05)
pole users – uživatelé, co jsou na rozvrhové akci zapsaní Každý uživatel má následující atributy:
username – uživatelské externí jméno
isteacher – atribut, íkající, jestli uživatel je učitelem/studentem (1/0) Problém:
P edměty v E-learningu se nesynchronizují se STAGem automaticky. Každý učitel si sám rozhoduje, bude-li kurz do E-learningu registrovat.
Tím pádem přibývá podmínka využití aplikace:
P edměty, pro které uživatelé budou chtít aplikaci pro správu projektu v GitLabu využívat, musejí být v E-learningu registrovány, v jiném p ípadě se jim místo rozvrhových akcí vypíše chybová hláška:
Obrázek 17 : Chybová hláška. Kurz není registrován v E-learningu.
38
8. Testování
Témě každá webová aplikace by se měla chovat podle nějakých p edpokladů.
P i vývoji by se ale mohlo stát, že něco změníme a nevšimneme si, že se chování aplikace nečekaně změnilo. Aby k tomu nedošlo, tak bychom museli po každé změně kontrolovat, zda je všechno stále v po ádku, což je časově náročné. Proto lepším ešením bude napsat sadu testů, které otestují všechny části aplikace, a po každé změně zdrojových kódů je provádět.
V Ruby on Rails je testování rozděleno do dvou částí: testování kontrolérů a testování modelů (tzv. functional a unit testy) [16]. Testy se provádějí klasicky pomocí tvrzení (assertions). Bude-li tvrzení vyhodnoceno jako false, ve výsledné statistice ho uvidíme jako „failure“, vyvolá-li navíc výjimku, zobrazí se ve statistice jako „error“.
Také se ve statistice zobrazí počet všech testů a tvrzení.
Generování testů v Rails
P i vytvo ení Rails aplikace se automaticky vytvo í i adresá Test, který bude udržovat testy a testovací data pro automatizované testování aplikace:
controllers/ – testy pro kontrolery
integration/ – testy vnit ní integrace (komunikace mezi jednotlivými komponentami)
unit/ – testy pro moduly
models/ – testy pro modely
fixtures/ – organizace testovacích dat
test_helper.rb – defaultní nastavení testů Testovací databáze
P i automatizovaném testování aplikace se pracuje se speciální testovací databází, nikoli s vývojovou databází. Nakonfigurovat ji můžeme v souboru
config/database.yml, v němž jsou definovány i jiné databáze (production, development).
39
test:
adapter: mysql encoding: utf8
database: diabase_name host: localhost
username: user
password: secret_pass
P i testování je vhodné mít v tabulkách nějaká data, která by vždy p ed spuštěním testů měla být stejná, aby byla jistota, že testy vždy dopadnou stejně. Pro tento účel jsou v Rails tzv. fixtures. P i každém spuštění testů se obsah existujících tabulek z databáze nahradí obsahem odpovídajících souborů.
one: #uživatel, který nedostane dostup k aplikací podle role ze stag login: alina.gutsul
token: UUBizJBzTEwoeE
two: #uživatel, který má přístup ale má neplatný token login: jiri.hnidek
token: 1234
P ed začátkem testování se občas může hodit nastavit p edem data, která se získávají mimo kontrolér či metodu. Pro takové účely existuje v Rails následující konstrukce:
setup do
TeamMember.delete_all #odstranění dat z tabulky @group_name = 'test group'
log_session #metoda, která provádí konfigurací GitLabu end
40 Testy pro aplikaci
Pro aplikaci jsem vytvo ila sadu funkčních testů, jejichž cílem je zjistit, jestli všechny kontroléry fungují správně v různých situacích. Níže uvádím jeden z testů, který bude platit pro všechny kontroléry. Cílem tohoto testu je pokusit se o zobrazení nějaké části aplikace bez požadované role „teacher“ ve STAGu. Podle návrhu by takový uživatel neměl získat p ístup. Testování provádím pomocí asserts: bylo-li vykonáno p esměrování na požadovanou adresu (stránku s chybovou hláškou).
test "should redirect because of no permissions" do request.env["eppn"] = 'alina.gutsul@tul.cz' get :index
assert_response :redirect
assert_redirected_to("/app/role-error.html") end
Komunikace s GitLabem je klíčovou částí aplikace, proto byl tento proces rozdělen na více metod a pro každou byly napsány unit testy. Když byly všechny metody jednotlivě otestovány, tak jsem vytvo ila i test, který zkontroluje celý proces vytvá ení skupiny projektů, jehož p íklad je uveden v p íloze C.
Provádí se test pro funkci create_group_with_projects, po jejímž ukončení se testuje, existuje-li v GitLabu skupina s požadovaným jménem, popisem, má-li správné členy a jestli byla do tabulky TeamMembers zapsána jména studentů, jejichž účty na GitLabu nebyly nalezeny.
Spuštění testů
Spustit testování aplikace můžeme dvěma způsoby:
zavolat určitý testovací soubor p íkazem ruby -Itest test/cesta_k_souboru
spustit všechny testy najednou pomocí p íkazu rake test
41
Na následujícím obrázku je vidět, že testy aplikace proběhly v po ádku. Celkem bylo napsáno 12 testů, využito 23 assertion.
Obrázek 18: Screenshot testovaní aplikace (rake test).
Tečky „“ označují vykonané testy. V p ípadě selhaní testu se zobrazí písmenko
„F“ (failure); dojde-li k nějaké chybě, zobrazí se písmenko „E“ (error).
Pomocí p íkazu rake statsje možné zobrazit statistiku napsané aplikace.
Obrázek 19: Statistika aplikace (rake stats)
42
Závěr
V rámci této bakalá ské práce jsem vytvo ila webovou aplikaci, která je v současné době dostupná na adrese magister.nti.tul.cz. Tato aplikace usnadňuje proces tvorby většího množství projektů v systému GitLab, umístěném na adrese gitlab.nti.tul.cz.
P istupovat do aplikace mohou pouze učitelé TU v Liberci, čehož bylo dosaženo dvoufázovou autentizací na základě technologie Shibboleth a role uživatele ve STAGu.
Magister.nti.tul.cz pomůže učitelům rychle a jednoduše vytvá et skupiny s projekty pro studenty podle rozvrhových akcí ze STAGu. V aplikaci se ohlídají všechny zatím známé chybové stavy, aniž by se uživatel musel o něco starat.
Aplikace je napsaná v jazyce Ruby a je podle MVC architektury rozdělená do t í částí Model-View-Controler. Dále ji také můžeme dělit na získání dat a vytvá ení skupin s projekty. Tyto dvě základní části jsou na sobě nezávislé.
Využití aplikace je zatím omezeno pouze na TU v Liberci. Bylo by obtížné ji využívat pro jinou organizací. Hlavním problémem je v tomto p ípadě získání seznamů lidi, pro které se budou vytvá et projekty. V aplikaci se to dělá pomocí REST webové služby od E-learningu. Pro komunikaci s GitLabem byl napsán modul s funkcí, který je více univerzální a dá se jednoduše rozší it.
Do budoucna by bylo možné změnit strukturu aplikace tak, aby byla více nezávislá na službě poskytující data. Také by bylo možné p idat p ehled všech existujících projektů v GitLabu a p ípadně další funkcionalitu, která p i využití aplikací bude pot ebná. Další věc, kterou by bylo dobré prozkoumat, je protokol OAuth2, který by vylepšil autentizaci do systému GitLab.
43
Seznam použité literatury
[1] GitLab TUL [online]. [cit. 2016-05-13]. Dostupné z: https:// gitlab.tul.cz/
[2] IS/STAG TUL [online]. [cit. 2016-05-13]. Dostupné z: https://stag.tul.cz/portal/
[3] IS/STAG ZCU [online]. [cit. 2016-05-13]. Dostupné z: http://is-stag.zcu.cz/
[4] Webové služby nad IS/STAG [online]. Dostupné z: https://stag-ws.tul.cz/ws/web/
[5] GitLab [online]. 2012 [cit. 2016-05-13]. Dostupné z: https://about.gitlab.com/
[6] GitLab API GitLab Documentation [online]. [cit. 2016-05-13]. Dostupné z:
http://docs.gitlab.com/ce/api/
[7] Shibboleth. Internet2 [online]. [cit. 2016-05-13]. Dostupné z:
http://www.internet2.edu/products-services/trust-identity/shibboleth/
[8] What's Shibboleth? Shibboleth [online]. [cit. 2016-05-14]. Dostupné z:
https://shibboleth.net/about/
[9] HNÍDEK, Ji í. Shibboleth [online]. 2016 [cit. 2016-05-14]. Dostupné z:
http://jirihnidek.github.io/2016/03/11/shibboleth/
[10] Shibboleth. In: Eduid [online]. CESNET, 2014 [cit. 2016-05-14]. Dostupné z:
http://www.eduid.cz/cs/tech/sp/shibb-2.4
[11] About Ruby. Ruby [online]. Ruby community [cit. 2016-05-14]. Dostupné z:
https://www.ruby-lang.org/en/about/
[12] TATE, B. a C. HIBS. Ruby on Rails: Up and Running. O‘Reilly Media, 2006.
ISBN: 978-0-596-10132-9
[13] CHACON S. a STRAUB B. Pro Git [online]. 2. Apress, 2014 [cit. 2016-05-14].
ISBN 978-14Ř4200773. Dostupné z: https://git-scm.com/book/en/v2/
[14] AKIYAMA, Toyokazu. OmniAuth Shibboleth strategy [online]. In: GitHub.
2016 [cit. 2016-05-14]. Dostupné z: https://github.com/toyokazu/omniauth- shibboleth
[15] ABBASOV, Nihad Gitlab [online]. In: GitHub. 2016 [cit. 2016-05-14].
Dostupné z: https://github.com/NARKOZ/gitlab
[16] RUBY, S., D. THOMAS a D. HANSSON.Agile Web Development with Rails 4:
The Pragmatic Programmers. Pragmatic Bookshelf, 2011. ISBN 978-1937785567 [17] MINA ÍK, Karel [online]. 2009 [cit. 2016-05-14]. Pět důvodů, proč zvolit Git
Dostupné z: https://www.zdrojak.cz/serialy/pet-duvodu-proc-zvolit-git/
[18] KUČERA, F. [online]. 2011[cit. 2016-05-14]. Distribuované verzovací systémy Dostupné z: http://www.abclinuxu.cz/clanky/distribuovane-verzovaci-systemy- uvod-1
44
A. Obsah přiloženého CD
P iložené CD obsahuje t i složky:
Dokumentace:
Obsahuje elektronickou podobu této práce ve formátech pdf, docx a doc.
Aplikace:
Složka app obsahující zdrojový kód vytvo ené aplikace.
Složka skript obsahující skript pro automatické vytvá ení dosud úspěšně nevytvo ených projektů
Manuál:
Obsahuje uživatelský manuál s ilustracemi k vytvo ené aplikaci.
45
B. Ukázka JSON/XML výstupu Webové služby nad IS/STAG
https://stag-ws.tul.cz/ws/services/rest/predmety/getPredmetyByStudent
?semestr=LS&osCislo=M13000097&outputFormat=#{FORMAT}
FORMAT = JSON:
[{"predmetStudenta":[
{"zkratka":"BS", "nazev":"Bakalářský seminář", "katedra":"ITE",
"rok":"2015","kredity":3},
{"zkratka":"MT", "nazev":"Multimediální technologie", "katedra":"ITE",
"rok":"2015","kredity":5},
{"zkratka":"PMZ","nazev":"Programování mobilních zařízení", "katedra":"MTI", rok":"2015","kredity":5}
] }]
FORMAT = XML:
<ns1:getPredmetyByStudentResponse xmlns:ns1="http://stag-ws.zcu.cz/">
<predmetyStudenta>
<predmetStudenta>
<zkratka>BS</zkratka>
<nazev>Bakalářský seminář</nazev>
<katedra>ITE</katedra>
<rok>2015</rok>
<kredity>3</kredity>
</predmetStudenta>
<predmetStudenta>
<zkratka>MT</zkratka>
<nazev>Multimediální technologie</nazev>
<katedra>ITE</katedra>
<rok>2015</rok>
<kredity>5</kredity>
</predmetStudenta>
</predmetyStudenta>
</ns1:getPredmetyByStudentResponse>
46
C. Kompletní test vytváření skupiny projektů
test "should create group with projects for students" do
create_group_with_projects(@group_name, @group_description, @key, @users) group = Gitlab.group_search(@group_name)[0] #get just created group group_members = Gitlab.group_members(group.id) #get members
assert_equal group.name, @group_name
assert_equal group.description, @group_description assert_equal group_members[0].name, 'alina.gutsul'
not_added_member = TeamMember.all.first #check table for not added users assert_equal not_added_member.member_name, 'alina'
assert_equal not_added_member.user_id, session[:user_id]
Gitlab.delete("/groups/#{group.id}?private_token=UUBizJBzTEwoEs9XEcxN") end
