Tiesitkö jatkuvan julkaisun olevan jo arkipäivää?

Muuttuiko Facebookin käyttöliittymä juuri eri näköiseksi? Ja minne ovat kadonneet ”under construction” -viestit verkkosivuilta? Kaiken takana on jatkuva julkaisu, jota sinunkin sähköisen palvelusi tulisi hyödyntää.

Pelkkää julkaisua

Yksi ohjelmistokehityksen megatrendeistä viime vuosina on ollut toisteisten töiden automatisointi. Automatisoinnilla haetaan säästöjä ja parempaa palvelun laatua. Esimerkiksi tiedon jalostaminen, ohjelmistojen testaus ja palvelinympäristöjen hallinta perustuvat vahvasti automaatioon. Palvelun päivittäminen uuteen versioon on perinteisesti ollut pitkä lista manuaalisia tehtäviä.

Sähköisiltä palveluilta lisäksi vaaditaan paljon. Käyttäjät odottavat palvelun vauhdikasta kehittymistä ja virheiden nopeaa korjausta. Palvelun päivittämisen uuteen versioon on tapahduttava huomaamattomasti. Työläs versiopäivitys kuormittaa henkilöresursseja ja vie huomion tärkeämmiltä tehtäviltä.

Jatkuvan julkaisun avulla muutokset palveluun tapahtuvat katkottomasti ja nopeasti.

Jatkuva julkaisu (eng. continuous deployment tai continuous delivery) tarkoittaa, että verkkopalvelu voidaan päivittää uuteen versioon koska tahansa. Jatkuvan julkaisun avulla muutokset palveluun tapahtuvat katkottomasti ja nopeasti. Tyypillisesti tämä tarkoittaa jatkuvaa, esimerkiksi päivittäistä, palvelun päivittämistä.

Continuous deployment -mallissa jokainen asennusvaihe on automaattinen, jolloin palveluun tehdyt muutokset julkaistaan välittömästi käyttäjille. Continuous deployment -mallissa jokainen uusi muutos on myös uusi julkaisu. Malli vaatii äärimmäistä kurinalaisuutta, koska myös uudet virheet siirtyvät automaattisesti seuraavaan versioon.

Niin ikään Continuous delivery -mallissa asennusvaiheet ovat automaattisia, mutta päätöksen tuotantoon viennistä tekee ihminen. Continuous delivery -mallissa jokainen uusi muutos on mahdollinen uusi julkaisu. Continuous delivery -malli on helpommin hallittavissa, koska virheet voidaan korjata ennen julkaisua. Molempien mallien mukainen rakentaminen on teknisesti hyvin samanlaista.

Julkaisuputkesta kulttuuriin

Alla olevassa kuvassa on kuvattu jatkuvan julkaisun vaatimukset. Jokainen uusi asennus tehdään automatisoidun julkaisuputken (eng. deployment pipeline tai build pipeline) kautta. Muutokset liikkuvat julkaisuputkessa käyden lävitse joukon laadunvarmistusvaiheita ja testausympäristöjä ja päätyen lopulta tuotantoon. Huolellisesti rakennettu julkaisuputki on vaatimus toimivalle jatkuvalle julkaisulle.

Jatkuvan integraation avulla palveluun tehdyt muutokset integroidaan yhdeksi kokonaisuudeksi. Mallin tarkoitus on varmistaa palvelun eheys aikaisessa vaiheessa. Jatkuvan integraation sydän on jatkuva integraatio -palvelin, joka tarkkailee muutoksia ja ohjaa ne automatisoidun julkaisuputken lävitse.

Jatkuva julkaisu vaatii ympärilleen testausautomaatiota. Testausautomaatiolla tarkoitetaan joukkoa etukäteen ohjelmoituja testejä, jotka voidaan ajaa automaattisesti. Testausautomaatioon kuuluvat usein mm. yksikkö-, integraatio-, regressio- ja suorituskykytestit. Korkeat testikattavuusrajat ovat yksi keino varmistaa julkaisujen vähäinen virheiden määrä.

Organisaation kulttuurin on lisäksi taivuttava jatkuvan julkaisun vaatimuksiin. Kehitystiimin on tehtävä töitä ketterästi ja pystyttävä rakentamaan jatkuva julkaisu osana muuta työtä. DevOps-toimintatapa on kriittistä, koska suuri osa jatkuvan palvelun rakentamistyöstä on muutoksia palvelimiin ja versiohallintaan. Tästä johtuen en suosittele erillisen käyttöpalvelutoimittajan käyttöä. Tuoteomistajan pitää olla läsnä ja hänellä tulee olla valtuudet päättää uusien versioiden asennuksista. Pilvipalvelun käyttö helpottaa jatkuvan julkaisun rakentamista, mutta ei ole pakollinen vaatimus.

jatkuvajulkaisu

Kannattava investointi

Monille yritykselle jatkuva julkaisu on ollut pitkään jo tärkeä osa heidän teknologiastrategiaansa. Amazon julkaisi uuden version palvelustaan joka 12 sekunti jo vuonna 2011. AirBnb-palvelussa uuden version asennus kestää kahdeksan minuuttia. Netflix on julkaissut oman jatkuvan julkaisun alustansa yleiseen käyttöön. Suomessa kehitetyt Fonectan palvelut ovat hyödyntäneet jatkuvaa julkaisua vuosikausia. Yritykset ovat ymmärtäneet jatkuvan julkaisun olevan investointi, joka kannattaa aina.

Ota jatkuva julkaisu käyttöön ja poista termi ”käyttökatko” sanavarastostasi.

Jatkuva julkaisu arkipäiväistyy nopeasti, kuten on käynyt lukemattomille ohjelmistokehityksen työtavoille. Teknologioiden kypsyminen ja tietoisuuden kasvaminen tekevät jatkuvan julkaisun rakentamisesta entistä helpompaa. Ensimmäinen versio jatkuvasta julkaisusta voidaan nykyään rakentaa muutamassa kuukaudessa. Ota sinäkin jatkuva julkaisu käyttöön ja poista termi ”käyttökatko” sanavarastostasi.

Blogisarjan seuraavassa osassa kuvaan, miten jatkuva julkaisu toteutettiin Työterveyslaitoksen ohjelmistokehityshankkeessa.

Lue lisää

Continuous Delivery Vs. Continuous Deployment: What’s the Diff?

Are you ready for Continuous Delivery?
Jatkuvan julkaisun mahdollistaminen ohjelmistokehityksessä
Global Continuous Delivery with Spinnaker
Engineering Culture at Airbnb
The Case for Continuous Delivery

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *

Liity joukkoon

Backend-kehittäjä

Helsinki, Jyväskylä, Tampere

Frontend-kehittäjä

Helsinki, Jyväskylä, Tampere