2. Analýza existujúcich riešení

Cieľom kapitoly je vymedziť problém, ktorý má navrhovaný nástroj riešiť. Nejde o ďalší systém na odovzdávanie programov ani o automatické určovanie známky. Predmetom pozorovania je pracovný postup, ktorý už prebieha v projektoch GitLab: problémy, vetvy, žiadosti o zlúčenie, revízie, testy a procesy CI/CD.

2.1 Kontext problému

DevOps spája technické postupy s tímovou prácou. Automatizované zostavenie alebo nasadenie nemá samo osebe pedagogický význam, ak študent nevie zmenu rozdeliť, zdokumentovať, posúdiť a opraviť na základe spätnej väzby. Výskum výučby DevOps preto zdôrazňuje praktickú prácu v súvislom procese, nie iba znalosť jednotlivých nástrojov.¹²³

Podobný záver vyplýva z výskumu revízie kódu. Revízia neslúži len na hľadanie chýb; podporuje aj zdieľanie znalostí a zlepšovanie riešenia.⁴ Počet komentárov preto nie je spoľahlivou náhradou za odborné posúdenie. Nástroj môže overiť, či diskusia vznikla a či autor reagoval, ale význam pripomienky musí posúdiť človek.

2.2 Pracovný postup vo výučbe

Predmety Základy softvérového inžinierstva a Základy DevOps používajú pri tímových zadaniach GitLab.⁵⁶ Študent pracuje s problémom, vytvorí vetvu a žiadosť o zlúčenie, doplní testy, zapojí spolužiakov do revízie a sleduje výsledok procesu CI/CD. Dôkaz o priebehu práce preto nie je na jednej obrazovke. Vyučujúci musí spájať údaje z viacerých objektov a opakovať rovnakú kontrolu pre viac projektov.

Požiadavky možno rozložiť na technické otázky R01-R13. Sledujú napríklad priradenie problému, pracovnú vetvu, žiadosť o zlúčenie, prítomnosť testov, prepojenie objektov, zapojenie posudzovateľov, odpovede autora, schválenie a úspešný proces CI/CD. Nie všetky výsledky majú rovnakú istotu. Stav procesu je priamo uložený údaj, zatiaľ čo zmysluplnosť komentára alebo kvalita kódu zostávajú predmetom ručného hodnotenia.

2.3 Existujúce skupiny riešení

Systémy automatizovaného hodnotenia

Artemis spája zadanie, repozitár, zostavenie, testovanie a spätnú väzbu v kontrolovanom vzdelávacom prostredí.⁷ Je vhodný na opakovateľné overenie funkčného výsledku. Táto práca však potrebuje pracovať nad už existujúcimi projektmi GitLab a sledovať históriu tímového postupu naprieč viacerými objektmi. Výučba revízie založená na vetvovom postupe je tomuto problému blízka, ale nepokrýva súhrnný pohľad na celý kurz.⁸

Analytika GitLab

GitLab poskytuje analytiku príspevkov, žiadostí o zlúčenie, problémov a procesov CI/CD.⁹ Údaj zostáva prepojený s pôvodným artefaktom, no vyučujúci ho musí ručne priradiť ku kritériám predmetu. Natívna analytika priamo neodpovie napríklad na otázku, či každý člen tímu posúdil požadovaný počet zmien a reagoval na pripomienky vo vlastnej žiadosti.

Kontrola konkrétnej zmeny

Danger vyhodnocuje pravidlá nad jednou žiadosťou o zlúčenie a výsledok vloží do jej diskusie.¹⁰ SonarQube používa statickú analýzu a kvalitatívne brány nad zdrojovým kódom.¹¹ Oba nástroje poskytujú rýchlu spätnú väzbu, ale nesledujú históriu jedného študenta naprieč viacerými projektmi a objektmi kurzu.

2.4 Porovnanie a vymedzenie medzery

✓ - priamo podporované, ~ - podporované čiastočne alebo po doplnení, - - nie je cieľom riešenia.

Porovnanie neznamená, že uvedené nástroje sú neúplné vo vzťahu k vlastnému účelu. Medzera vzniká až v konkrétnom prostredí výučby: projekty už existujú v GitLabe, vyučujúci potrebuje pohľad naprieč nimi a výsledok musí zostať overiteľným indikátorom, nie automatickou známkou.

Navrhované riešenie preto vytvára tenkú pedagogickú vrstvu nad GitLabom. Mapuje dostupné údaje na R01-R13, umožňuje zvoliť aktívne kontroly a prahy, zvýrazní skupiny vyžadujúce pozornosť a ponechá možnosť prejsť k pôvodnému artefaktu. Kvalita implementácie a skutočné porozumenie naďalej patria do ručného hodnotenia.