Älykkään ohjauksen digitaalisilla jalanjäljillä -artikkelisarjan ensimmäisessä osassa on kuvattu mihin eri ympäristöihin digitaaliset jalanjäljet kertyvät tietojenkäsittelyn projektiopinnoissa, sekä miten niitä aiotaan hyödyntää. Tässä artikkelissa keskitytään kuvaamaan miten projektinhallintaympäristön datan noudetaan ja muunnetaan XAPI-muotoon. Artikkeli sisältää teknisiä osuuksia, mutta näkökulma pyritään pitämään yleisellä tasolla.
Mikä Azure Devops?
Azure DevOps on ohjelmistoprojektien hallintaan suunnattu ympäristö. Sitä on mahdollista käyttää ohjelmistopalveluna (SaaS, Software as-a Service) tai paikallisesti asennettun palvelimen avulla. Ynpäristön kautta on mahdollista hallinnoida projektia ja siihen liittyvien aihioiden, ominaisuuksien, käyttäjätarinoiden ja tehtävien kehittämistä kehitysjonon avulla.
Azure DevOps –palvelun sisältämää dataa on mahdollista hakea ohjelmallisesti REST-rajapinnan kautta. Azure DevOps-palvelussa on oma rajapintansa useiden eri asioiden hakemiseen ja päivittämiseen. Kutsuja varten tarvitaan asentaa soveltuva käyttäjätunnus, sekä myöntää sille riittävät kehittäjätason oikeudet kyselyjen tekemiseen.
Miten REST-rajapintaa voidaan hyödyntää?
Käyttäjätunnukselle on määriteltävä Azure DevOpsissa henkilökohtainen pääsyavain (Personal Access Token, PAT), jotta kutsuja voi tehdä erillisen HTTP-pyynnön avulla. Pyynnön yhteydessä välitetään tarpeellinen avain. PAT luodaan käyttäjäkohtaisesti kirjatumalla ensiksi Azure Devops –palveluun, ja määrittämällä halutulle käyttäjätunnukselle uusi avain. Avaimen toiminta on rajattava päättymään tiettynä päivänä (maksimissaan sille voi antaa vuoden toiminta-ajan). Avaimelle on myös määriteltävä oikeudet haluttuun datajoukkoon.
REST-kutsuja on mahdollista tehdä esimerkiksi cURL-ohjelmalla, joka on komentorivityökalu datan siirtoon useiden eri verkkoprotokollien avulla. Itse kutsun tekeminen on yksinkertaista. Alla olevassa esimerkissä curl-ohjelman avulla haetaan kaikki organisaatioon luodut projektit JSON-muodossa.
curl -u :<PAT> https://dev.azure.com/<organisaatio>/_apis/projects?api-version=2.0
JSON-muotoinen data on tarkoitettu koneen luettavaksi, mutta sen muoto yksinkertaistettuna vastaa suurin piirtein alla olevaa esimerkkiä.
{”count”:7,
”value”:[{”id”:”<tunniste>”,
”name”:”Ryhmä X”,
”description”:”<Kuvaus>”,
”url”:”https://dev.azure.com/tiko-toimeksiantoprojekti2022/_apis/projects/<id>”,
”state”:”wellFormed”,
”revision”:105,
”visibility”:”private”,
”lastUpdateTime”:”2022-05-11T08:30:51.273Z”}]
}
Azure DevOpsin käsitteet ja toimijat
Datan käsittelyä varten tarvitsemme tietoa Azure DevOpsin projekteista, tiimeistä, tiimien jäsenistä, iteraatioista, workitemeistä, wikimerkinnöistä ja git-repojen kommiteista. Azure DevOpsissa nämä käsitteet rakentuvat hierarkisesti, joka vaikuttaa kyselyjen muodostamiseen REST-rajapinnan kautta. Tiimien jäsenyydet Azuressa täytyy olla määritetty opiskelijoille ryhmätiedon hakemista varten.
Kuten kuvasta 1 on havaittavissa, tiimi on organisaation alainen suoraan, mutta se voidaan liittää yhteen tai useampaan projektiin. Kehittäjät kuuluvat organisaatioon, ja ne voidaan asettaa tiimeihin tarpeen mukaan. Projektiiin kuuluu Wiki sekä versionhallintarepo kommitteineen. Kehitysjono on aina tiimikohtainen, samoin kuten iteraatiot, joita voi olla useita. Workitem kuuluu projektiin, ja se voidaan liittää myös kehitysjonoon.
Tiedonhakemisen toteuttaminen
Varsinainen tiedonhaku on mahdollista toteuttaa Linux-palvelimella komentotulkin skriptin, eli komentosarjakielitiedoston avulla, joka ajastetaan suoritettavaksi kerran vuorokaudessa. Skripti ajaa curl-ohjelman eri parametrein useamman kerran, sekä käsittelee ja yhdistää niiden palauttaman JSON-datan myöhempää käyttöä varten.
Projektien Workitemien noutamiseen ei pilotin toteutusaikaan ollut saatavilla suoraa API-kutsua, joka olisi samalla kertaa palauttanut kaikki tarvittavat tiedot. Halutut tiedot saatiin kuitenkin noudettua alla listatun WIQL-kyselyn avulla (Work Item Query Language). Se palauttaa Workitemien ID:t ja URLit halutusta projektista luontipäivän mukaan lajiteltuna ja syntaksiltaan muistuttaa paljon SQL-kieltä, jota käytetään tietokantakyselyissä.
Select [System.Id], [System.Title], [System.State], [System.TeamProject]
From WorkItems
WHERE [System.TeamProject] = <PROJEKTIN_NIMI> order by [System.CreatedDate] desc
Kuvassa 2 on havainnollistettu miten eri tiedot noudetaan Azuren REST-APIsta projektikohtaisesti, ja ne yhdistetään kategorioittain JSON-tiedostoihin muunnosohjelman käsittelyä varten. Käytännössä tämä tarkoittaa, että esimerkiksi yksi JSON-tiedosto pitää sisällään kaikki wikipäivitystapahtumat eroteltuna projektikohtaisesti. Sama tehdään versionhallintarepon kommiteille, tiimien kokoonpanoille, iteraatioille ja workitemeille. Jako on tarpeen, että voimme tehdä oletuksia datan sisällöstä ohjelman toteutuksen ja testauksen aikana. Lisäksi modulaarinen rakenne mahdollistaa virheellisen datan havaitsemisen helpommin kehitystyössä.
Data muodostetaan päivittäin projektien nykytilasta, ja koostetaan ladattavaksi visualisointia varten palvelimelle sijoittamatta sitä oppimistapahtumien tietovarastoon. Tämä eroaa esimerkiksi Moodlen datan noutamisesta, jossa tietovarastoon sijoitetaan yhden päivän tapahtumat kerrallaan, ja josta tiedot koostetaan palvelimelle. Mikään ei estäisi lukemasta päiväkohtaisia tapahtumia myös Azure Devopsin rajapinnan kautta, mutta niiden erottelu tietyn päivän perusteella tekisi tietoja hakevasta skriptistä monimutkaisemman, ja siten virhealttiimman.
XAPI-muunnos
Azure DevOpsin tuottaminen tapahtumien liittäminen oppikoppiin ei tuottanut varsinaisesti ongelmia, mutta kehitystyö toki vaati suunnittelua. Uusin tapahtumatyyppien lisääminen vaatii verbien ja id-tunnusten määrittämistä muunnosohjelmaan. Tämä tapahtuu käytännössä kirjoittamalla tarvittavat merkkijonot muunnosohjelman koodiin.
Tuotteenomistajan tehtäviin kuuluvat Workitemien hallintatapahtumat. Ne vaativat ehkä eniten pilkkomista pienempiin osiin, sillä Workitem voi olla aihio, ominaisuus, tarina, tehtävä, kehitysjonon alkio, virheraportti, testitapaus tai testikokoelma. Tapahtumia määrittävät käytännössä verbit lisäys, päivitys, hyväksyminen, aloitus ja valmistuminen.
Kehittäjän työtä kuvaavat tapahtumat keskittyvät lähes yksinomaan koodien kommitteihin ja vastaavasti SCRUM masterin toiminta wikipäivityksiin, joten näiden osalta muutoksia koodiin tarvitsi tehdä vähemmän verrattuna tuotteenomistajan toimintaan.
Yhteenveto
Räätälöidyn oppimisanalytiikka tarjoaa tässä tapauksessa selkeitä etuja kehitystyön tueksi. XAPIin nojaava ratkaisu on joustava, jolloin visualisointiin saadaan sovitettua dataa monesta eri lähteestä. Itse kehitetyt ja ylläpidetyt työkalut mahdollistavat sen, että ETL-prosessia voi kehittää tarpeen mukaan. Kehikon tukiessa jo datan automatisoitua noutamista, uuden kohteen lisääminen entisen joukkoon on suoraviivaista.
Kirjoittaja:
Anssi Gröhn, tietojenkäsittelyn lehtori, Älykäs ohjaus -hanke, Karelia-ammattikorkeakoulu