Preskočiť na obsah

1. Úvod

Spôsob, akým dnes priemysel vyvíja softvér, sa za posledné desaťročie zásadne zmenil. Veľkú časť tejto zmeny zhrnul pojem DevOps. Kim a kol. 1 ho popisujú ako súbor princípov, ktoré spájajú automatizáciu, priebežnú integráciu, priebežné dodávanie a tesnú spoluprácu medzi vývojom a prevádzkou softvérových produktov. Že nejde iba o rétorickú nálepku, ukázal výskum DORA (DevOps Research and Assessment): podniky, ktoré tieto postupy reálne zaviedli, nasadzujú do produkcie zhruba dvestokrát častejšie ako ostatné a od potvrdenia zmeny po jej nasadenie potrebujú asi stokrát menej času 2.

Univerzitná výučba sa s touto realitou ešte neporovnala. López-Fernández a kol. 3 v systematickom mapovaní odbornej literatúry ukázali, že ťažisko kurzov softvérového inžinierstva stále leží v teoretickej rovine; ďalšie výrazné oblasti, najmä prevádzka, automatizácia zostavenia a nasadenia, priebežná integrácia a systematická revízia kódu, bývajú pokryté iba povrchne, ak vôbec. Bobrov a kol. 4 k tomu dopĺňajú príznak, ktorý citovo poznajú aj kolegovia z praxe: vyučujúci jednoducho nemajú nástroj, s ktorým by im behom semestra niekto sledoval, ako sa študenti DevOps postupy učia dodržiavať.

Práve do tejto medzery spadá téma, ktorej sa venujem. Konkrétne ide o dva predmety vyučované na Katedre počítačov a informatiky Technickej univerzity v Košiciach: Základy softvérového inžinierstva a Základy DevOps. Vyučujúci v oboch zadáva tímový projekt na platforme GitLab; tým dostane jasné inštrukcie, aký má byť pracovný postup, ale počas semestra nežije takmer žiadnym spôsobom, ktorým by sa dalo overiť, či sa týchto inštrukcií naozaj drží. Príznakov je vždy niekoľko a vždy rôznych: jeden tím sa neobťažuje s problémami (angl. issues), iný ich má, ale nedotyčným spôsobom poprepája s vetvami, tretí posiela do hlavnej vetvy zmeny bez testov, štvrtý zase necháva potrubie priebežnej integrácie celý týždeň červené. Pre vyučujúceho je v morálne predstaviteľnom čase nemožné toto pri každom tíme zachytiť, hoci práve takto formulované čiastkové otázky tvoria jadro toho, čo sa od žiadosti o zlúčenie a revízie kódu čaká.

V súčasnosti je vyučujúci nútený tieto aspekty kontrolovať manuálne v rozhraní GitLab pre každý tím a každého študenta individuálne. V kontexte predmetov ZSI a Základy DevOps, ktoré spolu pokrývajú 17 študijných skupín a viac než 500 zapísaných študentov, ide o technicky neuskutočniteľnú úlohu. Dôsledkom je, že vyučujúci nemôže poskytnúť včasnú a adresnú spätnú väzbu, čo oslabuje efektivitu výučby. Študenti sa pritom správne naučia DevOps postupy len vtedy, keď ich opakovane aplikujú a dostávajú konštruktívnu spätnú väzbu o kvalite svojej práce 5. Tento problém som mal možnosť pozorovať aj osobne, keďže počas bakalárskeho štúdia som absolvoval predmet Základy softvérového inžinierstva a priamo som zažil situáciu, keď spätná väzba na dodržiavanie DevOps postupov prichádzala s výrazným oneskorením.

Závažnosť problému umocňuje aj rozdiel medzi tým, čo od absolventov očakáva softvérový priemysel, a tým, čo im súčasný kurikulárny model dokáže ponúknuť. Garousi a kol. 6 v rozsiahlej metaanalýze 33 štúdií ukázali, že priemerná medzera medzi vedomosťami absolventov a očakávanou úrovňou kompetencií v oblasti integračného a prevádzkového aspektu vývoja softvéru patrí medzi najväčšie v celom inžinierskom kurikule. Pang, Hindle a Barbosa 7 v kvalitatívnej štúdii postavenej na zakotvenej teórii dospeli k záveru, že hlavnou prekážkou výučby DevOps nie je nedostatok teoretického obsahu, ale absencia nástrojov, ktoré by umožnili priamo pozorovať tímové správanie študentov v priebehu semestra. Práve do tejto medzery zapadá riešenie navrhované v tejto práci.

1.1 Motivácia

Dôvodov, prečo má zmysel pustiť sa do tohto problému, je viac. V nasledujúcom texte popisujem konkrétne nedostatky, ktoré som pri oboch kurzoch postupne pozoroval, spolu s prínosmi, ktoré by ich odstránenie mohlo priniesť.

Prvým nedostatkom je neúmerná záťaž vyučujúceho. Aby vyučujúci v GitLabe vôbec zistil, ako konkrétny tím pracuje, musí prejsť históriu odovzdaní, otvorené aj zlúčené žiadosti o zlúčenie, komentáre k revíziám, stav potrubia a niekoľko ďalších artefaktov. Pri rozsahu, v akom oba kurzy dnes bežia (ZSI: 9 cvičebných skupín a 125 študentov, Základy DevOps: 8 projektových skupín a 382 študentov), takáto kontrola jednoducho prestáva byť realistická. V praxi to znamená, že väčšina študentov dostane spätnú väzbu so značným oneskorením, prípadne ju nedostane vôbec.

Ďalším závažným nedostatkom je nedostatok okamžitej spätnej väzby pre študentov. Výskum v oblasti vzdelávania v informatike preukázal, že efektívne učenie sa programátorských a inžinierskych praktík vyžaduje rýchlu a konkrétnu spätnú väzbu 8. Hattie a Timperley 9 pri syntéze viacerých starších metaanalýz argumentujú, že spätná väzba zameraná na konkrétnu úlohu a na spôsob jej riešenia patrí medzi najsilnejšie pôsobiace faktory na výsledky učenia, pričom jej účinok rapídne klesá so vzrastajúcim časovým odstupom od vykonanej činnosti. Z tohto dôvodu je oneskorenie typické pre manuálnu kontrolu DevOps postupov nielen organizačným problémom, ale priamo oslabuje pedagogický efekt celého predmetu. Bez automatizovaných nástrojov nemá študent informáciu o tom, či jeho pracovný postup zodpovedá požadovaným postupom, kým nedostane manuálne hodnotenie od vyučujúceho.

Tretím nedostatkom je nemožnosť objektívneho a porovnateľného hodnotenia. Bez štandardizovaných metrík je hodnotenie dodržiavania DevOps postupov nevyhnutne subjektívne. Rôzni vyučujúci môžu hodnotiť rovnaký tím odlišne, čo ohrozuje spravodlivosť hodnotenia. Leite a kol. 10 uvádzajú, že práve merateľnosť a pozorovateľnosť sú kľúčovými piliermi DevOps kultúry, preto by aj hodnotenie dodržiavania DevOps postupov malo byť založené na merateľných metrikách.

Štvrtým je riziko podvádzania a formálneho plnenia. Bez automatizovanej detekcie je pre vyučujúceho obtiažne identifikovať situácie, keď študenti formálne plnia požiadavky bez skutočného pochopenia DevOps postupov, napríklad vytváraním triviálnych žiadostí o zlúčenie, písaním generických komentárov k revíziám alebo sústreďovaním všetkej aktivity do posledných hodín pred termínom. Je dobre známe, že koncentrácia odovzdaní do úzkeho časového okna pred termínom súvisí so zvýšenou chybovosťou kódu 11, čo platí pre softvérovú prax aj pre študentské tímy.

A napokon, z hľadiska kvality výučby zásadný, je nedostatok opakovanej, štruktúrovanej praxe. Ericsson, Krampe a Tesch-Römer 12 ukázali, že nadobudnutie odbornej zručnosti vyžaduje cielenú, opakovanú prax s okamžitou opravou nedostatkov. Súčasná organizácia kurzu poskytuje jasné zadanie a jasné kritériá, no bez nástrojovej podpory sa cyklus "skúsim -> dostanem spätnú väzbu -> opravím" rozpadá na dlhé časové úseky, v ktorých študent pracuje bez vedomosti o tom, či sa pohybuje správnym smerom.

Predpokladaným prínosom riešenia stanoveného problému je návrh a realizácia sady pomocných nástrojov vrátane webovej platformy, ktoré budú automatizovane monitorovať aktivitu študentských tímov v GitLab prostredníctvom webhookov13, vyhodnocovať súlad ich pracovných postupov s definovanými DevOps pravidlami, poskytovať vyučujúcemu prehľadný informačný panel a generovať štruktúrované správy pre hodnotenie.

1.2 Formulácia úlohy

Z popísaného problému plynú konkrétne úlohy, ktoré v rámci tejto diplomovej práce riešim. Najprv potrebujem dôkladne porozumieť tomu, ako sú predmety Základy softvérového inžinierstva a Základy DevOps dnes organizované, čo presne pokrývajú a kde má manuálne hodnotenie najväčšie slepé miesta. Na tomto zistení potom staviam návrh a implementáciu nástrojov, ktoré sa integrujú s platformou GitLab a prevezmú časť rutinnej kontroly DevOps postupov; sústredím sa hlavne na tie kontroly, ktoré sú dnes pre vyučujúceho najťažšie udržateľné. Hotové riešenie však nemá zostať iba v rovine prototypu, preto ho v rámci práce skutočne nasadzujem do prevádzky a zbieram spätnú väzbu od vyučujúcich aj študentov priamo počas semestra. Z ich pripomienok a z vlastných pozorovaní vyplývajú zlepšenia, ktoré v ďalšom kole zapracovávam, pričom v závere vyhodnocujem, aký dopad malo nasadenie na organizáciu výučby a kvalitu spätnej väzby.


  1. Kim, G., Humble, J., Debois, P., Willis, J., Forsgren, N. The DevOps Handbook (2. vyd.), IT Revolution Press, 2021. 

  2. Forsgren, N., Humble, J., Kim, G. Accelerate: The Science of Lean Software and DevOps, IT Revolution Press, 2018. 

  3. López-Fernández, D. a kol. Teaching DevOps: A Systematic Mapping Study, IEEE Access, 2021. 

  4. Bobrov, E. a kol. Teaching DevOps in Academia and Industry: Reflections and Vision, DEVOPS 2019. 

  5. Christensen, H. B. Systematic Testing Should not be a Topic in the Computer Science Curriculum!, ITiCSE 2003. 

  6. Garousi, V. a kol. Software-engineering education: A systematic mapping study and a thematic synthesis, IST, 2019. 

  7. Pang, C., Hindle, A., Barbosa, D. Understanding DevOps Education with Grounded Theory, ICSE-SEET 2020. 

  8. Krusche, S., Bruegge, B. Continuous Software Engineering Education, ICSE-SEET 2018. 

  9. Hattie, J., Timperley, H. The Power of Feedback, Review of Educational Research, 2007. 

  10. Leite, L. a kol. A Survey of DevOps Concepts and Challenges, ACM Computing Surveys, 2019. 

  11. Eyolfson, J., Tan, L., Lam, P. Do time of day and developer experience affect commit bugginess?, MSR 2011 / EMSE 2014. 

  12. Ericsson, K. A., Krampe, R. T., Tesch-Römer, C. The Role of Deliberate Practice in the Acquisition of Expert Performance, Psychological Review, 1993. 

  13. https://docs.gitlab.com/ee/user/project/integrations/webhooks.html