Ohjelmistokehityksen automatisoituun julkaisuun tähtäävä prosessi koostuu ohjelmiston jatkuvasta integroinnista, jatkuvasta jakelusta ja jatkuvasta käyttöönotosta. Automaatio tehostaa tuotekehitystä ja parantaa ohjelmistoa kehittävän yrityksen kilpailukykyä markkinoilla. Jatkuvaa käyttöönottoa pilotoitiin kesällä 2022 naisten jalkapallon EM-turnausta varten tehdyllä veikkauskisasovelluksella. Sovellus julkaistiin Netlify-palvelussa, joka automatisoi käyttöönoton tehden uusien ohjelmistoversioiden julkaisusta nopeaa ja suoraviivaista.

Eräs ketterän ohjelmistokehityksen periaatteista on ”julkaise varhain ja julkaise usein”. Ohjelmointi aloitetaan hyvin varhaisessa vaiheessa tuotekehitystä, ja ohjelmakoodi muuttuu nopeasti, jopa useita kertoja saman päivän aikana. Koska koodi muuttuu koko ajan ja koska ohjelmoijia on useimmiten enemmän kuin yksi, tarvitaan versionhallintaratkaisu koodimuutosten hallintaan.

Paikkaa, jossa koodi versionhallintajärjestelmässä on, kutsutaan repositorioksi. Sieltä koodiin tehdyt muutokset pitää vielä saada julkaisuun joko testaus- tai tuotantoympäristöön.

Jatkuva integrointi

Jatkuva integrointi (Continuous Integration, CI) tarkoittaa niitä käytänteitä ja toimintatapoja, joilla ohjelmiston koodimuutosten integrointi repositorioon on automatisoitu työkaluihin tukeutuen. Automatisoinnin ohella CI-työkalujen tehtävä on varmistaa uuden tai muuttuneen koodin oikeellisuus. Prosessi perustuu testaukseen ja lähdekoodien yhdistämiseen (kuvio 1). [1]

Kuviossa tekstit: muutos ohjelmakoodissa käynnistää automaattisesti käännöksen. Jos käännös menee läpi, suoritetaan automatisoidut testit. Jos testit menevät läpi, ei eri kehittäjien koodit yhdistetään.
KUVIO 1. Jatkuva integrointi.

Jos ohjelmistokehityksessä ei käytetä jatkuvaa integrointia, kehittäjien on kommunikoimalla ja koordinoimalla sovittava keskenään versionhallintaan vietävistä koodimuutoksista. Tämä on ongelmallista, koska manuaalinen koordinointi vaikeutuu koodimäärän ja kehittäjämäärän kasvaessa. [1]

Jatkuva jakelu ja jatkuva käyttöönotto

Versionhallinta repositorioineen on ohjelmiston kehittäjiä varten. Ohjelmiston varsinaiset käyttäjät eivät useinkaan ole tietoisia versionhallintaratkaisuista. Voi jopa olla, että he eivät tiedä versionhallinnasta mitään, eikä heidän tarvitsekaan tietää. Ohjelmiston käyttäjien intressit ovat testaus- tai tuotantoympäristössä olevassa varsinaisessa ohjelmistossa. Ilman automaatiota ohjelmiston kehittäjien on erikseen huolehdittava siitä, että repositorioon kohdistuneet koodimuutokset päätyvät testaus- tai tuotantoympäristöön, kuten esimerkiksi web-palvelimelle, mikäli kyseessä on selaimella käytettävä web-sovellus.

Jatkuva jakelu (Continuous Delivery, CD) tarkoittaa sitä, että repositorioon kohdistuvien koodimuutosten perusteella ohjelmistosta käännetään automaattisesti uusi versio, joka onnistuneen käännöksen seurauksena voidaan viedä joko testaus- tai tuotantoympäristöön. Kun koodiin kohdistuneet muutokset päätyvät testaus- tai tuotantoympäristöön, ne näkyvät myös ohjelmiston varsinaisille käyttäjille versiopäivitysten muodossa. Jatkuva käyttöönotto (Continuous Deployment, CD) vie automaation astetta pidemmälle, sillä onnistuneen käännöksen seurauksena koodimuutokset viedään testaus- tai tuotantoympäristöön automaattisesti (kuvio 2). [2]

Kuviossa tekstit: Automaattinen julkaisu repositorioon. Jos käännös onnistuu, ohjelmiston uusi versio otetaan automaattisesti käyttöön.
KUVIO 2. Jatkuva jakelu ja jatkuva käyttöönotto.

CI/CD-putki

CI/CD-putki (pipeline) tarkoittaa automatisoitua prosessia, joka sisältää jatkuvan integroinnin, jatkuvan jakelun ja jatkuvan käyttöönoton. Putki määrittelee mitä missäkin vaiheessa tapahtuu. Määrittely tehdään CI/CD-työkalulla. CI/CD-putken (kuvio 3) tyypillisiä vaiheita ovat lähdekoodin muutos repositoriossa, käännös, testaus ja käyttöönotto. Kun repositorioon kohdistuu lähdekoodin muutos, CI/CD-työkalu käynnistää automaattisesti putkeen määritellyt toiminnot. Lähdekoodin muutosta seuraa tyypillisesti käännös. Mikäli se menee läpi, suoritetaan automatisoidut testit. Jos testit menevät läpi, ohjelmistosta otetaan käyttöön uusi versio. [3]

Kuviossa tekstit: Jos käännös menee läpi, suoritetaan automatisoidut testit. Jos testit menevät läpi, eri kehittäjien koodit yhdistetään. Jos käännös onnistuu, ohjelmiston uusi versio otetaan automaattisesti käyttöön.
KUVIO 3. CI/CD-putki.

Toimiva CI/CD-putki tehostaa tuotekehitystä ja mahdollistaa ohjelmistoa kehittävälle yritykselle paremman kilpailuaseman markkinoilla. Myös ohjelmiston ylläpidettävyys paranee ja tuen järjestäminen helpottuu. Hyvin rakennettu CI/CD-putki on automatisoitu, nopea, tietoturvallinen ja johdonmukainen. Se on lisäksi tiukasti integroitu versionhallintaan ja ongelmatilanteissa se kykenee osoittamaan ongelmakohdan putkessa. Tällaisen putken rakentamisen ja ylläpidon edellytys on ammattitaitoinen kehittäjätiimi. [4]

Jalkapallon EM-turnauksen veikkaussovellus

Naisten jalkapallon EM-turnaus järjestettiin Englannissa kesällä 2022. Turnausta varten kehitettiin sovellus veikkauskisan toteuttamiseksi. Jalkapallon arvoturnauksen veikkauskisa on aiemmin järjestetty kaksi kertaa käyttämällä Googlen työkaluja. Nyt haluttiin kehittää sovellus itse helpottamaan tulosten ja tulostaulun ylläpitoa. Toinen motivaattori oli ohjelmointi. Toisinaan on mukava ohjelmoida vapaa-ajalla jotain sellaista, jolla ei ole suoraa kytkentää opettajan työhön.

Veikkauskisasta informoitiin etukäteen tietojenkäsittelyn ja liiketalouden henkilöstöä, jotta osallistujamäärä oli selvillä ennen sovelluksen kehittämisen aloittamista. Kehittäminen päätettiin aloittaa, jos kisaan ilmoittautuu vähintään 5 osallistujaa. Lopulta 10 henkilöä ilmoittautui mukaan.

Sovelluksen kehittäminen käynnistyi ennen vapaajaksoa, mutta suurin osa kehittämisestä tapahtui vapaajakson kahden ensimmäisen viikon aikana. Sovelluksen julkaisusta ilmoitettiin osallistujille juhannuksen jälkeisenä maanantaina 27.6. Turnaus alkoi keskiviikkona 6.7., eli osallistujille jäi reilu viikko aikaa veikkauksien tekoon. Kaikki veikkaukset piti tehdä ennen turnauksen avauspeliä (kuva 1).

Valokuva jalkapallokatsomosta, jossa henkilö pitää kädessään Suomen naisten jalkapallojoukkueen kuvaa.
KUVA 1. Suomi-huumaa Milton Keynesissä (kuva: Sanna Rönkkö).

Sovellus koostuu rekisteröitymis- ja kirjautumissivuista, etusivusta, alkulohkoveikkauksesta, Suomi-veikkauksesta, Playoff-veikkauksesta, tulostaulusta ja chatista. Sovellus on kehitetty Reactilla mobiiliystävälliseksi Bootstrapiin perustuen. Sovelluksen tietokanta on Firebase Realtime Database. Kuvassa 2 on sovelluksen kirjautumisen jälkeinen etusivu, joka näyttää kuluvan päivän ottelut.

Kuvakaappaus sovelluksen etusivusta EM 2022 veikkauskisa.
KUVA 2. Sovelluksen etusivu.

Alkulohkoveikkauksessa veikattiin jokaisen alkulohko-ottelun tulos 1X2-menetelmällä. Alkulohkoja turnauksessa oli neljä ja jokaisessa alkulohkossa oli neljä maata. Alkulohkojen otteluita turnauksessa oli yhteensä 24. Kuvassa 3 on alkulohkoveikkauksen näkymän alkuosa ennen turnauksen alkamista ja alkulohkovaiheen päättymisen jälkeen.

Kuviossa teksti: Alkulohkoveikkaus, lohko A. Valitse pelin voittaja tai tasapeli. Saat pisteen jokaisesta oikeasta tuloksesta. Veikkaaja on saanut alkulohkoveikkauksesta 16/24 pistettä.
KUVA 3. Alkulohkoveikkauksen näkymän alkuosa ennen turnauksen alkamista ja alkulohkovaiheen päättymisen jälkeen.

Suomi-veikkauksessa veikattiin Suomen alkulohko-otteluiden maalimäärät, Suomen sijoitus alkulohkossa sekä Suomen menestyminen turnauksessa. Kuva 4 on Suomi-veikkauksen näkymän alkuosa ennen turnauksen alkamista ja Suomen alkulohko-otteluiden päättymisen jälkeen.

Kuviossa on erilaisia Helmarit-veikkauksia, jotka on pitänyt teidä ennen ensimmäistä peliä. Esimerkissä on Espanja-Suomi-pelin maalilukuveikkaus.
KUVA 4. Suomi-veikkauksen näkymän alkuosa ennen turnauksen alkamista ja Suomen alkulohko-otteluiden päättymisen jälkeen.

Playoff-veikkauksessa veikattiin turnauksen eri vaiheista jatkoon pääsevät joukkueet siten, että veikkauksen ensimmäisessä vaiheessa alkulohkoista valittiin 8 puolivälieriin selviytyvää joukkuetta. Sen jälkeen veikkaus jatkui valitsemalla neljä välieriin selviytyvää joukkuetta. Kolmannessa vaiheessa valittiin kaksi finalistia ja Playoff-veikkauksen päätti mestarin valinta kahdesta finalistista. Kuvassa 5 näkyy Playoff-veikkauksen näkymän alkuosa ennen turnauksen alkamista ja Playoff-vaiheen päättymisen jälkeen.

Kuviossa on Playoff-veikkaus.
KUVA 5. Playoff-veikkauksen näkymän alkuosa ennen turnauksen alkamista ja Playoff-vaiheen päättymisen jälkeen.

Tulostaulu sisälsi osallistujat lajiteltuna kertyneen pistemäärän perusteella. Tulostaulussa osallistujasta näkyi pelkästään nimimerkki siihen saakka, kun kyseisen osallistujan mestariveikkaus meni pieleen.

Liiketalouden osaston naiset ottivat kisassa kaksoisvoiton. Kisan voitti ylivoimaisesti Teija Harju, joka osallistui veikkauskisaan nimimerkillä Hillahullu. Toisesta sijasta käytiin kova kamppailu ja lopulta sen vei nimiinsä Sanna Rönkkö nimimerkillä paminkello. Kuvassa 6 näkyy tulostaulun näkymän alkuosa (kaksi parasta) turnauksen päättymisen jälkeen.

Kuviossa tulostaulu.
KUVA 6. Tulostaulu-näkymän alkuosa turnauksen päättymisen jälkeen.

Esimerkki jatkuvasta käyttöönotosta

Jotta edellä kuvatun kaltaisen sovelluksen voi julkaista verkossa, tarvitaan palvelu, jossa julkaisun voi tehdä. Julkaisuun oli aluksi kaksi vaihtoehtoa: Microsoft Azure ja Heroku. Ensin päädyttiin kokeilemaan Azurea, joka oli ennestään tuttu työn puolesta. Parin tunnin jälkeen tultiin siihen johtopäätökseen, että Azure on aivan liian järeä palvelu yksittäisen sovelluksen julkaisuun. Sen jälkeen tutustuttiin Herokun dokumentaatioon, joka ei innostanut.

Lopulta päädyttiin kartoittamaan muita palveluita ja löydettiin Netlify-palvelu. Sen dokumentaation ja tutoriaalien perusteella muodostui käsitys helposta ja suoraviivaisesta käyttöönotosta. Palveluun rekisteröidyttiin ja aloitettiin sovelluksen ensimmäinen käyttöönotto. Palvelu tarjoaa useita eri tapoja sovelluksen käyttöönottoon.

Käyttöönotto tehtiin kuvassa 7 esitetyn prosessin mukaan tuomalla koodit palveluun Git-repositoriosta. Tämä edellyttää niin kutsutun kolmannen osapuolen oikeuksien antamista Netlifylle GitHubin repositorioon. Ensimmäisessä vaiheessa valitaan Git-versionhallinnan toimittaja, kuten esimerkiksi GitHub-palvelu. Sen jälkeen GitHub-palvelusta valitaan repositorio, jonka koodit halutaan ottaa käyttöön. Lopuksi palvelussa määritellään sivuston ja sen kääntämisen asetukset, sekä tehdään ensimmäinen käyttöönotto.

Kuviossa tekstit: Import an existing project from a Git repository. 1. Connect to Git provider. 2. Pick a repository. 3. Site settings, and deploy.
KUVA 7. Sovelluksen käyttöönoton vaiheet Netlify-palvelussa, kun käyttöönotto tehdään Git-repositoriosta.

Käyttöönotto oli kokonaisuutena helppoa. Ainoa pieni ongelma alussa oli se, että sovelluksen kehittämisessä käytetty paikallisen ympäristön Node.js-versio oli eri kuin palvelun oletusversio. Netlifyn foorumilta löytyi kuitenkin nopeasti ratkaisu ongelmaan, jonka jälkeen palvelu määriteltiin käyttämään sitä Node.js-versiota, jota sovelluksen kehittämisessä oli käytetty.

Jatkuva käyttöönotto Netlifyn palvelulla toimi hyvin. Kun GitHubin repositorioon vietiin koodimuutoksia ensimmäisen käännöksen jälkeen, palvelu tunnisti koodimuutokset automaattisesti ja käynnisti välittömästi käännöksen, jonka edistymistä pystyttiin seuraamaan Netlifyn palvelussa.

Käännökset tapahtuivat nopeasti alle minuutissa, pois lukien ensimmäinen käännös. Onnistuneen käännöksen jälkeen sovelluksen uusi versio oli saman tien käyttäjien saatavilla eli tässä tapauksessa tuotantoympäristössä. Kuvissa 8 ja 9 näkyy viimeisimmän käännöslokin alkuosa ja loppuosa Netlify-palvelussa.

Kuviossa deploy log kellonaikoineen.
KUVA 8. Sovelluksen viimeisimmän käännöslokin alkuosa Netlify-palvelussa.
Kuviossa deploy log kellonaikoineen.
KUVA 9. Sovelluksen viimeisimmän käännöslokin loppuosa Netlify-palvelussa.

Positiivinen automaatiokokemus

Paikallinen kehitysympäristö yhdessä versionhallinnan kanssa on kätevä, mutta rajoitteinen ratkaisu. Jotta sovelluksen voisi julkaista verkossa, tarvitaan palvelu. Veikkauskisasovelluksen julkaisuun onnistuttiin löytämään palvelu, jolla sovelluksen jatkuvan käyttöönoton pystyi toteuttamaan vaivattomasti ja nopeasti.

Ohjelmistokehityksessä automatisoinnilla on tärkeä rooli. Veikkauskisasovelluksen jatkuvan käyttöönoton pilotti tarjosi positiivisen automaatiokokemuksen, jota on mahdollista hyödyntää myös opettajan työssä monin tavoin. Esimerkkeinä opetus ja hankkeet, joilla voi olla tarve hankkeissa kehitettävien sovelluksien julkaisuille. Myös sovelluksen kehittämisessä onnistuttiin, sillä veikkauskisa saatiin vietyä läpi ongelmitta.

Sovelluksen kehittäminen täysin opetuksen ulkopuolella toi hauskaa vaihtelua opettajan työhön. Yhteisöllisyyden näkökulmasta veikkauskisa tarjosi osallistujille mahdollisuuden olla tekemisissä kollegoiden kanssa työn ulkopuolella.


Pekka Ojala
lehtori
Oulun ammattikorkeakoulu, Informaatiotekniikan yksikkö, tietojenkäsittely


Lähteet

[1] Rehkopf, M. 2022. What is continuous integration? Atlassian. Hakupäivä 2.9.2022. https://www.atlassian.com/continuous-delivery/continuous-integration

[2] Pittet, S. 2022. Continuous integration vs. delivery vs. deployment. Atlassian. Hakupäivä 2.9.2022. https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment

[3] Red Hat. 2022. What is a CI/CD pipeline? Hakupäivä 2.9.2022. https://www.redhat.com/en/topics/devops/what-is-ci-cd?sc_cid=7013a000002pwNlAAI&gclid=CjwKCAjwu5yYBhAjEiwAKXk_eKoPaWSnJwFf4b1YPDqnMpjK_qCh28uqDl5CRpW15H9vphD1c7gBsBoCtzcQAvD_BwE&gclsrc=aw.ds

[4] Bigelow, S. J. 2022. CI/CD pipelines explained: Everything you need to know. Tech Accelerator. Hakupäivä 2.9.2022. https://www.techtarget.com/searchsoftwarequality/CI-CD-pipelines-explained-Everything-you-need-to-know

Post Views: 1 891