3. Preskúmanie možností riešenia¶
Z analýzy v predchádzajúcej kapitole vyplynulo, že žiadne z existujúcich riešení nepokrýva všetky požiadavky kladené na nástroj pre podporu výučby DevOps. Skôr než pristúpim k návrhu vlastného riešenia, považujem za rozumné skontrolovať si dve praktické otázky priamo na dátach. Tou prvou je, či vôbec rozhranie GitLabu pre udalosti dáva dosť bohatý obraz o dianí v repozitári na to, aby z neho bolo možné automatizovane vyhodnotiť kontrolný zoznam vyučujúceho z kapitoly 2. Druhou otázkou je, koľko z tohto zoznamu reálne pokryjú už existujúce nástroje vybrané z kategórií podľa sekcií 2.3.1 až 2.3.3, ak by sme ich nasadili priamo na ZSI projekt. Nesnažím sa pritom vybrať jeden konkrétny nástroj a odporučiť ho; cieľom je získať empiricky podloženú predstavu o tom, čo už je hotové a čo bude potrebné navrhnúť.
3.1 Cieľ a metóda experimentu¶
Experiment som rozdelil do dvoch častí. Prvá časť overuje pokrytie kontrolného zoznamu udalosťami, ktoré GitLab dokáže emitovať pri zmene stavu repozitára. Druhá časť overuje, ako sa s rovnakým zoznamom vyrovnajú vybrané existujúce nástroje. Nezávisle premennou je v oboch prípadoch položka kontrolného zoznamu, závislou je miera pokrytia.
Mieru pokrytia hodnotím trojstupňovou škálou: položka je plne pokrytá (✓), ak je možné ju automatizovane vyhodnotiť bez doplnkových údajov; čiastočne pokrytá (~), ak je dostupná len časť údajov alebo je potrebné ďalšie spracovanie; a nepokrytá (-), ak údaje chýbajú alebo nie sú strojovo zachytiteľné. Toto škálovanie zodpovedá konvencii použitej v analytickej tabuľke v sekcii 2.4 a zachováva porovnateľnosť medzi oboma časťami experimentu.
Ako vstupné dáta pre obe časti experimentu som použil vlastný GitLab projekt s menším počtom umelo vygenerovaných žiadostí o zlúčenie a komentárov, ktoré simulujú typické situácie pozorované v ZSI: triviálnu žiadosť bez popisu, kvalitnú žiadosť s odkazom na problém a testami, ako aj zámerne podozrivé správanie typu okamžitého schválenia bez komentára. Tento postup nadväzuje na odporúčanie Bassa, Webera a Zhua 1, podľa ktorých má byť pozorovateľnosť DevOps praktík overovaná na konkrétnych, presne ohraničených scenároch.
3.2 Pokrytie zoznamu webhookmi¶
Webhooky GitLab umožňujú emitovať JSON správy pri vybraných udalostiach (Push, Merge Request, Note, Pipeline, Issue, Tag Push). Pre každú udalosť som zaznamenal obsah doručeného tela správy a následne overoval, ktoré položky kontrolného zoznamu z kapitoly 2 z nej možno odvodiť.
Z merania vyplynulo, že najbohatším zdrojom informácií je udalosť Merge Request, ktorá obsahuje identifikátor priradeného a revízora, názov a popis žiadosti, odkazy na prepojené problémy, zoznam zmenených súborov a aktuálny stav potrubia. Druhým kľúčovým zdrojom je udalosť Note, ktorá popri texte komentára nesie aj jeho diskusné vlákno a pozíciu v diferencii kódu, čo umožňuje rozlišovať medzi všeobecnými a k riadku viazanými revíznymi komentármi. Udalosť Push poskytuje úplný zoznam odovzdaní vrátane správ, autora a časovej pečiatky, čo umožňuje aj následnú analýzu rozloženia aktivity v čase. Pre kontrolu konvencie pomenovania vetiev je dostupný odkaz na zdrojovú vetvu už v udalosti Merge Request, takže overenie nevyžaduje dodatočné volanie rozhrania.
Niektoré položky však neboli pokryté priamo. Konkrétne nedostupný je výsledok statickej analýzy a konkrétne pokrytie testami; tieto údaje sú síce viditeľné v potrubí CI/CD, no webhook ich neobsahuje, je teda potrebné ich získať doplnkovým volaním REST API3. Podobne, údaj o tom, či revízor svoj komentár formuloval ako konštruktívny, alebo iba potvrdzujúci, nie je možné určiť priamo zo štruktúry, ale len analýzou textu.
Tabuľka pokrytia sumarizuje výsledky tejto časti experimentu pre desať najdôležitejších položiek zoznamu.
| Kontrolná položka | Webhook | REST API |
|---|---|---|
| Priradenie problému členovi tímu | ✓ | ✓ |
| Vytvorenie pracovnej vetvy podľa konvencie | ✓ | ✓ |
| Žiadosť o zlúčenie obsahuje popis a odkaz na problém | ✓ | ✓ |
| Žiadosť má dvoch posudzovateľov v rolách assignee a reviewer | ✓ | ✓ |
| Komentáre revízie sú viazané na konkrétny riadok kódu | ✓ | ✓ |
| Zmysluplnosť textu komentárov | - | ~ |
| Pridané jednotkové testy v zmene | ~ | ✓ |
| Stav potrubia CI/CD pre žiadosť | ✓ | ✓ |
| Pokrytie testami pre zmenené súbory | - | ~ |
| Rozloženie odovzdaní v čase semestra | ✓ | ✓ |
✓ - plne pokryté, ~ - čiastočne pokryté, - - nepokryté.
Z tabuľky je zrejmé, že kombinácia webhookov a doplnkového volania REST API dokáže pokryť všetky kvantitatívne overiteľné položky. Kvalitatívne posúdenie zmysluplnosti textu komentárov a konštruktívnosti revízie zostáva oblasťou, kde nepostačujú metadáta a je potrebné navrhnúť doplnkový mechanizmus, napríklad heuristickú analýzu textu doplnenú o jednoduché modely strojového učenia. Toto zistenie priamo formuje smerovanie navrhovaného riešenia.
3.3 Pokus s existujúcimi nástrojmi¶
V druhej časti experimentu som overoval, do akej miery dokážu existujúce nástroje pokryť kontrolný zoznam, ak ich nasadíme priamo na rovnaký GitLab projekt. Do experimentu som zaradil GitLab Analytics, nástroj Danger4 v konfigurácii pravidiel description-required, linked-issue a tests-changed a vstavaný report o pokrytí, ktorý dáva GitLab k dispozícii v potrubí. Artemis a CodeGrade som do tejto časti nezaradil, pretože vyžadujú vlastnú infraštruktúru a odovzdávaný kód, čo je nezlučiteľné s modelom práce v ZSI.
GitLab Analytics potvrdil zistenie z analytickej kapitoly: poskytuje agregované grafy odovzdaní a žiadostí o zlúčenie, no neumožňuje odpovedať na otázku, či konkrétny študent splnil pravidlo. Štatistika je ďalej viazaná na jeden projekt, takže pri viac než tucte projektových repozitárov v oboch sledovaných predmetoch by vyučujúci musel prechádzať desiatky samostatných obrazoviek.
Nástroj Danger pokryl prekvapivo dobre časť pravidiel, ktoré sa dajú vyjadriť v jazyku JavaScript pri otvorení žiadosti o zlúčenie. Skript úspešne identifikoval žiadosti bez popisu, bez prepojeného problému aj zmeny, ktoré nepridali žiadne testovacie súbory. Nástroj však pracuje iba na úrovni jednej žiadosti, nedokáže odpovedať na otázku, či študent ako celok splnil počas semestra minimálne jednu autorskú a dve revízne aktivity. Pri pokuse o rozšírenie pravidla na detekciu rýchlych schválení (žiadosť schválená v priebehu desiatok sekúnd po vytvorení) bol potrebný vlastný skript volajúci API mimo Danger, čím sa stratila výhoda z jeho použitia.
Vstavaná správa o pokrytí kódu fungovala technicky správne, no vyžaduje, aby ju každý tím samostatne nakonfiguroval v potrubí, čo by naprieč všetkými projektovými repozitármi viedlo k nutnosti centrálne udržiavať šablónu. Tento prvok preto bude rozumné riešiť centrálne na strane navrhovaného nástroja a nie ponechať jeho konfiguráciu na tímy, čo zodpovedá odporúčaniu Sadowského a kol. 2, podľa ktorého je centrálne škálovaná tooling-platforma stabilnejšia ako delegovanie konfigurácie na tímy.
3.4 Závery z experimentu¶
Experimentálne preskúmanie potvrdilo dve kľúčové východiská pre návrh vlastného riešenia. Prvým je technická realizovateľnosť: potrebná množina údajov je dostupná prostredníctvom kombinácie webhookov a REST API a ich získavanie nevyžaduje žiadnu zmenu na strane GitLab inštalácie, na ktorej už projekty bežia. Druhým je nedostatočnosť parciálnych nástrojov: žiadny zo skúmaných nástrojov neposkytuje agregovaný pohľad naprieč tímami a žiadny nepokrýva kvalitatívnu zložku revíznej komunikácie.
Z týchto pozorovaní vyplývajú tri rozhodnutia pre návrh, ktoré detailne rozpracujem v ďalšej kapitole. Riešenie bude udalosťami riadeným systémom prijímajúcim webhooky GitLab a obohacujúcim ich REST volaniami. Hodnotenie bude pracovať na úrovni jednotlivého študenta v rámci celého semestra, nie na úrovni jednej žiadosti. A napokon, kvalitatívna zložka revíznej komunikácie sa bude posudzovať doplnkovou heuristikou, ktorej výsledok bude vyučujúcemu predkladaný ako návrh, nie ako konečné rozhodnutie. Tým ostane pedagogická zodpovednosť na vyučujúcom a riešenie zostane v súlade s princípom, že nástroj má učiteľa odbremeniť, nie nahradiť.