DevOps <3 Integraatio?

Integraatiot ja DevOps-malli ovat eri maailmasta, mutta saako näitä maailmoja kohtaamaan? Kyllä. Integraatiotiimit voivat hyödyntää DevOps-toimintamallia omassa toiminnassaan ainakin kuudella tavalla.

integraatio devops.jpg

Toisin kuin perinteisessä ohjelmistokehityksessä, integraatioiden varsinaiset haasteet ovat usein muualla kuin itse tekniikassa ja kehitysprosessissa. Monesti yrityksen sisällä ollaan organisoiduttu liiketoimintaprosessien ja järjestelmien ympärille. Tällöin integraatioita toteutettaessa törmätään usein organisaation sekä kumppaniverkoston erilaisuuksiin.

On erilaisia teknologioita, arkkitehtuureja, tietomalleja, toimintamalleja, liiketoimintamalleja sekä aikataulutuksia. Integraatioiden tehtävä on saada nämä juttelemaan keskenään ja vaihtamaan tietoa sujuvasti.

Prosessien automatisointi vaatii sillan liiketoimintapäätöksistä teknisiin ratkaisuihin. Integraatiotiimin tärkeimpiä tehtäviä on tämän mahdollistaminen. Voidaanko tässä hyödyntää ohjelmistokehityksestä tuttua DevOps-toimintamallia? Tässä tarjoan 6 vinkkiä, miten DevOps-maailmasta tuttuja asioita voi ja pitää hyödyntää nykyajan integraatioiden toteutuksessa.

1.     Automatisoitu testaus

Vaikka integraatioiden testaaminen ei ole yhtä yksinkertaista kuin ohjelmistojen, johtuen pitkälti hankaluudesta simuloida taustajärjestelmiä, niin testauksen voi nykyaikaisilla työkaluilla automatisoida. Taustajärjestelmiä on mahdollista simuloida esimerkiksi palveluiden virtualisoinnilla. Testauksessa on syytä testata jokainen integraatio kattavasti virhesyötteineen eikä pelkästään ”happy-path” -skenaariota.

2.     Automatisoitu käännösputki

Automatisoitu käännösputki versionhallinnasta tuotantoon on ollut normikäytäntö ohjelmistotuotannossa jo pidemmän aikaa ja sama käytäntö on täysin toteutettavissa integraatioissa, myös ESB:n kanssa. Oleellista on tässäkin vähentää manuaalista työtä, jotta integraatioiden käännös, testaus ja asennus tapahtuvat aina samalla tavalla, automatisoidusti. Pienikin muutos joutuu aina kulkemaan käännösputken ja regressiotestien kautta, jolla varmistutaan, että muutos ei aiheuta perhosefektiä.

3.     Konfiguraationhallinta

Lähtökohtaisesti integraatiot ovat järjestelmien välistä konfiguraatiota. Jos pystymme hallitsemaan ja versioimaan tätä konfiguraatiota jollain konfiguraationhallinnan työkalulla, pystymme tällöin hallinnoimaan ja mallintamaan järjestelmien välistä integraatioviidakkoa selkeällä työkalulla. Konfiguraationhallinta säilyttää koko muutoshistorian ja versioi jokaisen muutoksen järjestelmään. Näin on mahdollista päästä käsiksi mahdollisten integraatio-ongelmien juurisyihin ja tarpeen vaatiessa palauttaa toimiva konfiguraatio.

4. Infrastruktuurin provisiointi

Kuinka usein ohjelmistokehityksessä on tilanne, jossa tuotantopalvelin on niin monimutkaisen kompleksinen pannu, että sitä säilytetään kassakaapissa kolmen eri lukituksen takana, jotta sille ei tapahtuisi mitään? Tällaisia palvelimia kutsutaan lumihiutale-palvelimiksi. DevOps-ajattelussa tavoitteena on kohdella palvelimia kuin karjaa, ei lemmikkejä. Palvelimia pitää pystyä polkaisemaan pystyyn tyhjästä minuuteissa.

Integraatiot ovat koko yrityksen toiminnan kannalta keskiössä, jos integraatiot eivät toimi, koko yritys seisoo paikallaan. Poikkeustilanteista toipuminen on usein paljon nopeampaa, mikäli vanha palvelin ajetaan alas ja se korvataan uudella identtisellä palvelimella ja konfiguraatioilla. Mikäli provisiointi ja konfiguraationhallinta ovat kunnossa, tämä pystytään tekemään minuuteissa.

5. Nopeat keskitetyt palautekanavat

Kun integraatioissa tulee ongelmia, on erittäin tärkeää, että siitä saadaan tieto oikeille henkilöille mahdollisimman nopeasti. Mielellään jopa ennen kuin vika varsinaisesti huomataan loppukäyttäjien toimesta. Tällöin järjestelmässä tulee olla nopeat palautekanavat, jotka virheen kriittisyydestä riippuen informoivat automaattisesti oikeaa tahoa.

Integraatioiden kanssa ongelman selvitys on usein vielä hankalampaa kuin ohjelmistokehityksessä. On vaikea tietää, onko vika lähettävässä järjestelmässä, integraatioratkaisussa vai vastaanottavassa järjestelmässä. Lisäksi sanoma saattaa integraatioratkaisuissa kulkea usean eri prosessin läpi. Pahimmassa tapauksessa virheen selvittäjä voi ongelman paikallistamiseksi joutua kirjautumaan 10 eri palvelimelle ja kahlaamaan läpi lukemattomia lokitiedostoja. Tällöin yrityksen olisi syytä hankkia keskitetty lokienhallinta järjestelmä, joka kerää lokit yhteen paikkaan. Kyseisestä järjestelmästä voi sitten suorittaa hakuja suoraan selaimesta ja virheen paikallistaminen nopeutuu moninkertaisesti. Samaa järjestelmää voi myös hyödyntää antamaan tilannekuvaa koko järjestelmän tilasta ja toiminnasta.

6. Automatisoitu mallinnus ja dokumentaatio

Mallinnusta sivuttiin jo aiemmin konfiguraationhallinnan kohdalla. Ketterä ja DevOps-mallin mukainen kehittäminen ei jätä pois sitä tosiasiaa, että järjestelmän tila ja integraatiot pitää olla dokumentoitu ajantasaisesti. Tässä piilee suuri riski, mikäli integraatioita tuotetaan useista eri paikoista ja nopealla syklillä. Millä varmistetaan, että dokumentaatio pysyy ajan tasalla varsinkin, kun halutaan välissä tehdä nopeita koestuksia?

Entä jos dokumentoinnissa tapahtuu inhimillinen virhe ja se ei vastaakaan todellisuutta? Vastaus tähänkin on automaatio. Mikäli integraatioiden tila voidaan versioida ja ylläpitää konfiguraationhallinnalla, on tällöin mahdollista myös mallintaa tuo tila ja täten luoda dokumentaation päivityksestä yksi osa yksittäisen integraation automaatista käännösputkea. Dokumentaatio pysyy tällöin aina ajan tasalla ja koska se on luotu suoraan versioidusta konfiguraatiosta, ei sisällä virheitä.

Kaipaatko lisää tietoa ketteristä integraatioista? Kuuntele tuore webinaarimme:

Kuuntele webinaari!

integraatio   DevOps




Tero Niemistö | Tiimiesimies, teknologiajohtaja

Tero Niemistö | Tiimiesimies, teknologiajohtaja

Tero on ”managerisoitunut” pitkän linjan arkkitehti. Noin 14 teknisen vuoden jälkeen Tero siirtyi esimiesrooliin tahtonaan johtaa alan huippuasiantuntijoita kuten itseään haluaa johdettavan. ”Esimiehen tärkein tehtävä on mahdollistaa alaistensa onnistuminen”, Tero sanoo. Teron johtamisfilosofiassa esimies ei ole perinteisen hierarkisen mallin mukaisesti joukkojen yläpuolella vaan tukee heidän päivittäistä työtä alhaalta. Hän haluaa olla läsnä ja kiinnostunut alaistensa arjesta sekä tukea heitä sparraamalla ja valmentamalla niin usein kuin mahdollista. Kun Tero laittaa ns. haalarit päälle ja kädet saveen, niin hänet löytää usein julistamassa DevOps-kulttuurin ilosanomaa ja rakentamassa sovelluskehityshankkeisiin täysin automatisoitua jatkuvan julkaisun putkea.

Kirjoittajan kaikki blogitekstit

Tilaa blogikirjoitukset sähköpostiisi




Seuraa meitä somessa

LinkedIn Twitter Facebook YouTube