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

Cieľom tejto kapitoly je preskúmať, ako vyzerá výučba DevOps z odborného aj inštitucionálneho hľadiska a aké nástroje má vyučujúci dnes pri ruke. Vychádzam pritom z dvoch perspektív. Prvou je všeobecná, odbornými publikáciami opísaná podoba DevOps ako disciplíny, vrátane kompetencií, ktoré by mal absolvent ovládať. Druhou je konkrétna situácia na Katedre počítačov a informatiky, kde sa tieto kompetencie reálne učia. V závere kapitoly zhrniem to, čo v existujúcich riešeniach chýba; práve tieto medzery sú motiváciou pre návrh, ktorý popisujem ďalej.

2.1 DevOps ako disciplína a kľúčové kompetencie¶

Pojem DevOps vznikol v roku 2009 a od svojho vzniku prešiel výrazným vývojom od neformálneho hnutia po štruktúrovanú disciplínu s definovanými princípmi a praxou. Podľa Leiteho a kol. ¹ je DevOps možné charakterizovať prostredníctvom piatich kľúčových dimenzií: spolupráca, automatizácia, priebežná integrácia, priebežné dodávanie a monitorovanie. Luz, Pinto a Bonifácio ² na základe prípadovej štúdie v reálnom prostredí potvrdzujú, že úspešná adopcia DevOps vyžaduje kombináciu technických nástrojov aj organizačnej kultúry. Ebert a kol. ³ dopĺňajú, že DevOps nie je len súborom nástrojov, ale predovšetkým kultúrnou zmenou, ktorá odstraňuje bariéry medzi vývojom a prevádzkou softvérových systémov.

Z praktického hľadiska je možné identifikovať nasledujúce kľúčové kompetencie, ktoré by študent základov DevOps mal ovládať:

• Správa verzií a pracovné postupy s vetvami. Študent musí ovládať prácu so systémom Git, t. j. vytvárať vetvy podľa konvencií a spájať zmeny prostredníctvom žiadostí o zlúčenie ⁴.
• Priebežná integrácia a priebežné dodávanie. Študent musí rozumieť konceptu CI/CD potrubia, teda automatizovanému procesu zostavenia, testovania a nasadenia softvéru spúšťaného pri každej zmene v zdrojovom kóde ^{4 19}.
• Automatizované testovanie. Súčasťou každej zmeny by mali byť jednotkové testy, ktoré overujú korektnosť implementácie. Christensen ⁵ argumentuje, že systematické testovanie by nemalo byť vyučované izolovane, ale ako integrálna súčasť vývojového procesu.
• Revízia kódu. Každá zmena by mala prejsť revíziou od iného člena tímu, pričom revízia by mala byť zmysluplná a konštruktívna ⁶.
• Správa úloh a prepojenie zmien s problémami. Práca na projekte by mala byť organizovaná prostredníctvom systému na sledovanie problémov (angl. issue tracker), pričom každá zmena v kóde by mala byť prepojená s konkrétnym problémom ⁷.

Bass, Weber a Zhu ⁷ zdôrazňujú, že efektívne osvojenie si DevOps kompetencií vyžaduje praktické skúsenosti na reálnych projektoch, pretože teoretické vedomosti bez praktickej aplikácie nevedú k zmene pracovných návykov. Práve preto je potrebné, aby výučba DevOps bola podporená nástrojmi, ktoré umožňujú monitorovať praktickú aplikáciu týchto kompetencií.

Empirické štúdie zo softvérového priemyslu poskytujú zaujímavý kontext pre to, ako tieto kompetencie vyzerajú v ostrej praxi. Bacchelli a Bird ⁸ v rámci pozorovania revízie kódu v spoločnosti Microsoft zistili, že hoci motiváciou revízie býva najmä hľadanie chýb, dominantnou prínosnou aktivitou je v skutočnosti zdieľanie znalostí o kóde a zlepšovanie čitateľnosti, čo predpokladá zmysluplné, nie generické komentáre. Sadowski a kol. ⁹ pri analýze procesu revízií v spoločnosti Google ukázali, že priemerný čas na prvú odozvu od revízora je menší ako jedna hodina a že práve táto rýchlosť má kľúčový vplyv na plynulosť dodávky. McIntosh a kol. ¹⁰ zase na projektoch Qt, VTK a ITK ukázali, že mieru chýb vo zverejnených zmenách možno štatisticky významne predpovedať z rozsahu zapojenia revízorov, čo potvrdzuje opodstatnenosť požiadavky na účasť dvoch posudzovateľov v ZSI. Beller a kol. ¹¹ pri rozsiahlom skúmaní revízií v projektoch s otvoreným zdrojovým kódom zistili, že len menšia časť pripomienok sa venuje funkčnosti a väčšina sa týka štýlu, údržby a čitateľnosti, čo napovedá, že študenti sa vďaka revízii učia predovšetkým konvencie tímovej práce. Pre testovanie sú zase relevantné zistenia Erdogmusa, Morisia a Torchiana ¹², ktorí v kontrolovanom experimente preukázali, že prístup test-first vedie k vyššej produktivite aj kvalite testov v porovnaní s následným testovaním, čo posilňuje opodstatnenosť požiadavky, aby každá žiadosť o zlúčenie obsahovala jednotkové testy.

2.2 Súčasný stav výučby DevOps na univerzitách¶

Systematické mapovanie realizované Lópezom-Fernándezom a kol. ¹³ identifikovalo 35 primárnych štúdií venovaných výučbe DevOps v akademickom prostredí publikovaných medzi rokmi 2015 a 2021. Z ich analýzy vyplývajú nasledujúce zistenia.

Predovšetkým, väčšina kurzov začleňujúcich DevOps sa zameriava len na vybrané aspekty, najčastejšie na priebežnú integráciu a automatizované testovanie, zatiaľ čo komplexný pracovný postup zahŕňajúci správu problémov, revíziu kódu, konvencie pre pomenovanie vetiev a systematické dodávanie je vyučovaný len v malom počte kurzov.

Navyše, hodnotenie dodržiavania DevOps postupov je vo väčšine kurzov realizované manuálne vyučujúcim na konci semestra, čo neumožňuje poskytnúť priebežnú spätnú väzbu. Bobrov a kol. ¹⁴ potvrdzujú tento záver a uvádzajú, že priemerný vyučujúci venuje manuálnej kontrole GitLab repozitárov 3 až 5 hodín týždenne, čo je pri väčšom počte tímov neudržateľné.

Napokon, špecializované nástroje pre automatizované hodnotenie DevOps postupov sú zriedkavé. Zatiaľ čo pre hodnotenie kvality zdrojového kódu, automatické testovanie a detekciu plagiátov existuje množstvo nástrojov, pre komplexné hodnotenie dodržiavania DevOps pracovných postupov v prostredí GitLab takýto nástroj v čase písania tejto práce neexistuje.

Pohľad na problematiku zo strany praxe upozorňuje na rovnakú medzeru. Smeds, Nybom a Porres ¹⁵ v prieskume medzi inžiniermi identifikovali, že najčastejšie prekážky pri zavádzaní DevOps nesúvisia so znalosťou jednotlivých nástrojov, ale s osvojením postupov pre prácu s vetvami a revíziou kódu na tímovej úrovni. Senapathi, Buchan a Osman ¹⁶ pri prípadovej štúdii v jednej veľkej organizácii poukázali na to, že úspešná tranzícia na DevOps trvala viac ako tri roky a bola brzdená predovšetkým ľudskými, nie technickými faktormi. Wiedemann, Wiesche, Gewald a Krcmar ¹⁷ z longitudinálnej analýzy 30 prípadových štúdií dospeli k záveru, že DevOps je v súčasnosti skôr meniacim sa súborom postupov než ucelenou metodikou, čo komplikuje jeho výučbu na univerzitách. Fitzgerald a Stol ¹⁸ v rámcovom prehľade konceptu continuous software engineering zdôrazňujú, že priebežná integrácia, dodávanie a prevádzka tvoria jeden kontinuálny tok aktivít, ktorý nemožno hodnotiť v izolovaných statických ukazovateľoch. Táto myšlienka priamo motivuje voľbu dynamického, udalosťami riadeného mechanizmu pre nástroj navrhnutý v tejto práci.

Podľa správy State of DevOps²⁰ organizácia Google identifikovala štyri kľúčové metriky výkonnosti dodávky softvéru: frekvenciu nasadenia, čas od potvrdenia zmeny po nasadenie, čas obnovy po výpadku a mieru zlyhania zmien. Tieto metriky sú systematicky merateľné a poskytujú objektívny základ pre hodnotenie úrovne adopcie DevOps postupov. Avšak v akademickom prostredí neboli tieto metriky dosiaľ systematicky aplikované pri hodnotení študentských tímov.

Konkrétnym príkladom tejto situácie je výučba na Katedre počítačov a informatiky Technickej univerzity v Košiciach, kde sa DevOps praktiky dotýkajú dvoch predmetov.

Predmet Základy softvérového inžinierstva²¹ (ďalej ZSI) si kladie za cieľ naučiť študentov pracovať v tíme, aplikovať postupy softvérového inžinierstva a riadiť menšie softvérové projekty. Hodnotenie predmetu pozostáva z cvičení (20 bodov) a skúšky (80 bodov). Cvičenia zahŕňajú tri komponenty: analytickú úlohu (9 bodov), tímový projekt (9 bodov) a aktivitu na cvičeniach (2 body). Tímový projekt je realizovaný v rámci cvičebných skupín na platforme GitLab, pričom od študentov sa vyžaduje dodržiavanie definovaného pracovného postupu.

Pracovný postup pre riešenie jednej úlohy v rámci tímového projektu je nasledovný. Študent si priradí existujúci problém (angl. issue), vytvorí pracovnú vetvu a implementuje riešenie vrátane jednotkových testov. Po dokončení vytvorí žiadosť o zlúčenie (angl. merge request) s popisom zmien a prepojením na príslušný problém. Každú žiadosť musia posúdiť dvaja ďalší členovia tímu: jeden v úlohe priradeného (angl. assignee) a druhý v úlohe revízora (angl. reviewer). Obaja posudzujú kvalitu kódu, zmysluplnosť testov a dodržiavanie dohodnutých konvencií. Ak identifikujú nedostatky, autor zmeny ich musí opraviť a znovu predložiť na posúdenie. Po schválení obidvoma posudzovateľmi sa zmena zlúči do hlavnej vetvy a príslušný problém sa uzavrie. Každý člen tímu musí počas semestra vyriešiť minimálne jednu úlohu ako autor a posúdiť minimálne dve žiadosti, jednu ako priradený a jednu ako revízor.

Predmet Základy DevOps nadväzuje na ZSI²² a je štruktúrovaný do dvoch tematických oblastí: prvá sa zameriava na nástroje (Git, Docker, CI/CD) a druhá na procesy a komunikáciu (správa problémov, testovanie, revízia kódu). Hodnotenie pozostáva z testu v 7. týždni semestra (10 bodov), tímového projektu (10 bodov) a skúšky (80 bodov). Tímový projekt vyžaduje vyriešenie zadanej úlohy vrátane implementácie jednotkových testov, revíziu kódu ostatných členov tímu a zlúčenie ich riešení do hlavnej vetvy. Oproti ZSI tento predmet pridáva požiadavky na konfiguráciu potrubí CI/CD a automatizované nasadenie.

V rámci hodnotenia tímovej spolupráce vyučujúci v súčasnosti manuálne overuje pre každého študenta viac ako desať kritérií. Medzi ne patrí napríklad to, či si študent priradil problém, či vytvoril vetvu a žiadosť o zlúčenie so zmysluplným popisom a či žiadosť prepojil s príslušným problémom. Ďalej sa kontroluje, či je implementácia primeranej kvality, či študent napísal testy a či sú správy k odovzdaniam zmysluplné (nie generické správy typu "a"). Okrem toho sa hodnotí, či študent vykonal konštruktívnu revíziu kódu, či upravil vlastný kód na základe spätnej väzby od kolegov a či zlúčil zodpovedajúcu žiadosť. Táto kontrola sa musí vykonať pre každého člena každej skupiny individuálne, čo pri 9 cvičebných skupinách ZSI so 125 študentmi a 8 projektových skupinách Základov DevOps s 382 študentmi potvrdzuje neudržateľnosť manuálneho prístupu popísanú vyššie.

2.3 Existujúce nástroje pre automatizované hodnotenie¶

V tejto časti analyzujem existujúce nástroje a prístupy, ktoré čiastočne pokrývajú problém automatizovaného hodnotenia v kontexte softvérového inžinierstva. Identifikoval som tri kategórie relevantných nástrojov: systémy automatizovaného hodnotenia programovania, nástroje pre analýzu repozitárov a nástroje pre analýzu dodržiavania pravidiel.

2.3.1 Systémy automatizovaného hodnotenia programovania¶

Systémy automatizovaného hodnotenia, ako sú napríklad Artemis²³ a CodeGrade²⁴, sa primárne zameriavajú na automatické vyhodnotenie korektnosti študentského kódu prostredníctvom testovacej sady. Tieto systémy overujú, či odovzdaný kód produkuje očakávané výstupy pre definované vstupy.

Krusche a Bruegge ⁶ v rámci platformy Artemis rozšírili automatizované hodnotenie o model revízie kódu, kde študenti vzájomne posudzujú kvalitu kódu podľa definovaných kritérií. Tento prístup je prínosný pre rozvoj kompetencií v oblasti revízie kódu, avšak má niekoľko obmedzení v kontexte výučby DevOps:

• Hodnotenie sa zameriava výlučne na kvalitu kódu a revízie, nezohľadňuje širší DevOps pracovný postup (správu vetiev, prepojenie s problémami, stav potrubia).
• Systém vyžaduje vlastnú infraštruktúru a nie je priamo prepojený s priemyselne používanými platformami ako GitLab.
• Spätná väzba sa poskytuje po odovzdaní úlohy, nie v reálnom čase počas vývoja.

2.3.2 Systémy pre analýzu repozitárov¶

Druhou kategóriou sú nástroje pre analýzu Git repozitárov, ktoré poskytujú štatistiky o aktivite vývojárov. Medzi ne patrí napríklad vstavaná analytika GitLab²⁵, GitInspector²⁶ alebo GrimoireLab²⁷.

Vstavaná analytika GitLab poskytuje základné metriky ako počet odovzdaní (angl. commits) na člena, prehľad potrubia a zoznam žiadostí o zlúčenie. Tieto údaje sú užitočné pre rýchly prehľad, avšak majú významné obmedzenia:

• Neposkytujú hodnotenie súladu s definovanými pravidlami, napríklad neoverujú, či vetvy dodržiavajú konvencie pomenovania alebo či žiadosť o zlúčenie odkazuje na konkrétny problém.
• Neumožňujú definovať vlastné kontrolné pravidlá prispôsobené požiadavkám konkrétneho kurzu.
• Štatistiky sú dostupné len na úrovni jedného projektu, nevytvárajú súhrnný prehľad naprieč všetkými tímami kurzu.
• Neposkytujú detekciu podvádzania, napríklad identifikáciu generických revízií, okamžitého schvaľovania alebo sústreďovania aktivity pred termínom.

Nástroj GitInspector je konzolová aplikácia, ktorá analyzuje Git repozitár a generuje správu o príspevkoch jednotlivých autorov. Nástroj GrimoireLab je komplexná platforma pre analýzu komunitných softvérových projektov. Oba nástroje sú primárne určené pre analýzu projektov s otvoreným zdrojovým kódom, nie pre akademické hodnotenie, a neposkytujú hodnotenie podľa definovaných DevOps pravidiel.

2.3.3 Nástroje pre analýzu dodržiavania pravidiel¶

Tretiu kategóriu tvoria nástroje slúžiace na automatizovanú kontrolu dodržiavania pravidiel v priemyselnom prostredí. Medzi nich patrí napríklad Danger²⁸, ktorý automatizovane komentuje žiadosti o zlúčenie na základe definovaných pravidiel (napríklad chýbajúci opis, priveľké zmeny, chýbajúce testy). Ďalším príkladom sú nástroje pre statickú analýzu kódu integrované priamo do potrubí CI/CD, ako je SonarQube²⁹.

Tieto nástroje sú prínosné pre automatizáciu kontroly kvality, avšak nie sú navrhnuté pre vzdelávacie prostredie. Konkrétne majú nasledovné nedostatky:

• Neposkytujú súhrnný pohľad naprieč viacerými tímami a študentmi, sú navrhnuté pre jeden projekt a jeden tím.
• Nemajú mechanizmus hodnotenia a zobrazovania výsledkov pre vyučujúceho.
• Nepodporujú konfiguráciu pravidiel prispôsobenú akademickému kontextu (napríklad hodnotenie podľa týždňov semestra).
• Nedokážu detekovať vzorce podvádzania špecifické pre akademické prostredie.

2.4 Zhrnutie analýzy a identifikácia medzier¶

Na základe analýzy existujúcich prístupov a nástrojov je možné konštatovať, že v súčasnosti neexistuje nástroj, ktorý by komplexne riešil problém automatizovanej podpory výučby DevOps postupov v univerzitnom prostredí s nasledovnými vlastnosťami:

1. Integrácia s priemyselnou platformou. Riešenie by malo byť priamo integrované s platformou GitLab, ktorú študenti používajú na prácu s repozitármi, čo eliminuje potrebu ďalšieho nástroja a umožňuje monitorovanie v reálnom prostredí.
2. Automatizované hodnotenie súladu. Riešenie by malo automatizovane overovať dodržiavanie definovaných DevOps pravidiel, od konvencií pomenovania vetiev, cez revíziu kódu, až po stav potrubí CI/CD.
3. Spätná väzba v reálnom čase. Výsledky hodnotenia by mali byť dostupné okamžite po vykonaní aktivity, nie s oneskorením dní alebo týždňov.
4. Správa viacerých tímov. Nástroj musí umožňovať vyučujúcemu súhrnný pohľad na všetky tímy kurzu s možnosťou podrobného náhľadu na jednotlivých študentov.
5. Detekcia podvádzania. Riešenie by malo identifikovať vzorce, ktoré naznačujú formálne plnenie požiadaviek bez skutočného pochopenia DevOps postupov.
6. Konfigurovateľnosť. Pravidlá hodnotenia by mali byť prispôsobiteľné požiadavkám konkrétneho kurzu a jeho progresii počas semestra.

Tabuľka Porovnanie sumarizuje porovnanie analyzovaných nástrojov s identifikovanými požiadavkami.

✓ - spĺňa, ~ - čiastočne spĺňa, - - nespĺňa.

Z tabuľky je zrejmé, že žiadny z existujúcich nástrojov nespĺňa všetky identifikované požiadavky. Artemis a CodeGrade sú silné v automatizovanom hodnotení programovania, avšak nie sú integrované s GitLab a nehodnotia DevOps pracovné postupy. GitLab Analytics a Danger poskytujú integráciu s GitLab, avšak nepodporujú komplexné hodnotenie súladu naprieč viacerými tímami. Žiadny z analyzovaných nástrojov neposkytuje detekciu podvádzania v kontexte DevOps postupov.

Z mojej analýzy vyplýva, že identifikovaná medzera v existujúcich riešeniach potvrdzuje opodstatnenosť navrhovaného riešenia: sady pomocných nástrojov integrovaných s platformou GitLab, ktoré budú v reálnom čase monitorovať aktivitu študentských tímov a automatizovane vyhodnocovať dodržiavanie DevOps postupov. Návrhu tohto riešenia sa venujem v ďalšej časti práce.