LFCA: Opi DevOpsin peruskäsitteet – Osa 21

DevOps on ollut trendikäs aihe jo jonkin aikaa ja on onnistunut kiinnittämään niin teknologia-ammattilaisten kuin yritystenkin huomion. Aloittelijana voi olla haastavaa kääriä päänsä DevOps-konseptin ympärille, ja tässä aiheessa täsmennetään tämän Internet-muotisanan peruskäsitteitä.

Aluksi DevOps on kahden sanan portti: kehitys ja toiminta. Se on joukko käytäntöjä ja työkaluja, jotka edistävät kehitystiimien (Devs) ja toimintojen (Ops) välistä yhteistyötä. DevOpsin tavoitteena on virtaviivaistaa ohjelmistokehityksen elinkaarta, minimoida vikatiheys, skaalata käyttöönottotiheyttä ja saavuttaa korkealaatuinen ohjelmisto.

Saadaksesi paremman käsityksen DevOpsista nykypäivän modernissa IT-ympäristössä, katsotaanpa, millainen käyttöönottomalli oli ennen DevOpsin tuloa.

Perinteiset IT-käytännöt

Ennen DevOpsia kehitystiimit ja laadunvarmistusinsinöörit käyttivät klassista vesiputousmallia. Työympäristö oli suurelta osin hiljentynyt ja sovellusten testaus ja käyttöönotto tapahtui täysin eristyksissä. Tämä johti tehtävien päällekkäisyyksiin, aukkoihin, palautteen viivästymiseen ja muihin tehottomuuteen, jotka vaativat lisäaikaa projektin loppuun saattamiseen. Rajoitettu ja viivästynyt palaute johti siihen, että ohjelmiston laatua ei tarkastettu perusteellisesti ennen viimeistä kehitysvaihetta.

Lisäksi koodin manuaalinen käyttöönotto johtui inhimillisistä virheistä, ja siksi se vaati enemmän aikaa sovellusten virheenkorjauksessa. Lisäksi eri tiimeillä oli erilaiset aikataulut tehtäviensä suorittamiselle, ja ei ollut harvinaista, että aikataulut putosivat tahdista, mikä viivästytti lisää lopputuotteen toteutumista.

DevOps-konseptin keksi joskus vuosina 2007–2010 kaksi kehittäjää: Andrew Shafer ja Patrick Debois. Se on perustamisestaan lähtien edistänyt sujuvaa yhteistyötä käyttö- ja kehitystiimien välillä ohjelmistokehityksen elinkaaren jokaisessa vaiheessa. Tämä ennusti uusia konsepteja, kuten Continuous Integration (CI) ja Continuous Delivery (CD) ja monia muita, jotka edistävät nopeaa ohjelmistotoimitusta.

DevOps-malli ja käytännöt

DevOps ei ole vain yhteistyötä ja oikeanlaista ajattelutapaa tavoitteen saavuttamiseksi. Se sisältää parhaat käytännöt, joiden tarkoituksena on auttaa toimittamaan laadukkaita ja markkinavalmiita ohjelmistoja mahdollisimman lyhyessä ajassa. Katsotaanpa joitain näistä parhaista käytännöistä, jotka auttavat sinua tehostamaan ja nopeuttamaan koodin toimittamista.

Continuous Integration on ohjelmistokehityskäytäntö, jossa kehittäjät yhdistävät koodimuutokset yhdeksi keskustietovarastoon. Tämän jälkeen koodille suoritetaan automaattiset testit ja koontiversiot. Jatkuvan integraation tavoitteena on nopeuttaa sovellusten virheenkorjausta, lyhentää uusien ohjelmistopäivitysten julkaisemiseen kuluvaa aikaa ja parantaa ohjelmiston laatua.

Continuous Delivery (CD) on jälleen yksi käytäntö, jossa muutokset koodiin rakennetaan automaattisesti ja otetaan käyttöön voimakasta testausta varten. Myöhemmin käyttöönotettua koodia vastaan suoritetaan automaattisia testejä, jotta kehittäjät voivat tunnistaa ja korjata virheet. Yleensä koodille tehdään asteittain useita testausympäristöjä, joissa standardien automaattisen prosessin kautta koodi saavuttaa korkeimman laatumerkin.

Suosittuja CI/CD-työkaluja ovat Jenkins, Travis CI, Circle CI, Azure DevOps ja AWS Code build.

Jatkuvan testauksen tavoitteena on tunnistaa vikoja ja mahdollisia riskejä ohjelmistokehityksen elinkaaren alkuvaiheessa, jotta lopputuotteessa ilmenevät virheet voidaan minimoida. Kun koodi epäonnistuu voimakkaissa testeissä, se lähetetään yleensä takaisin kehittäjälle tarkistettavaksi ennen kuin se lähetetään laadunvarmistusosastolle arvioita ja toiminnallista testausta varten. Laajalti käytettyjä jatkuvan testauksen työkaluja ovat Travis ja Selenium.

Kuten arvata saattaa, sovellukset ja taustalla oleva infrastruktuuri vaativat jatkuvaa seurantaa, jotta niiden suorituskyvyn identiteetit voidaan tarkistaa mahdollisten virheiden tai vikojen varalta ja varmistaa, että ne ovat eri alan standardien mukaisia. Valvotaan monenlaisia mittareita, mukaan lukien:

• Muistin ja suorittimen käyttö
• Levytilan käyttö
• Kaistanleveyden käyttö
• Asiakasvuorovaikutus

Seuraamalla ja analysoimalla sovellusten luomia tietoja ja lokeja kehittäjät voivat helposti saada käsityksen siitä, miten ominaisuudet tai kokoonpanot vaikuttavat käyttäjiin. Lisäksi hälytysten määrittäminen auttaa tunnistamaan virheet tai ei-toivotut muutokset joka vaiheessa. Jatkuva seuranta varmistaa viime kädessä sovellusten korkean käytettävyyden ja herättää luottamusta siihen, että asiat toimivat odotetusti.

Suosittuja seurantatyökaluja ovat muun muassa Prometheus, Netdata.

Lyhennettynä IaC, Infrastructure as Code kuvataan resurssien, kuten virtuaalipalvelimien ja kuormantasainten, käyttöönottoa ja hallintaa käyttämällä koneellisesti luettavia määritystiedostoja interaktiivisten määritystyökalujen sijaan. Tämä on erityisen tärkeää pilviympäristöissä, kuten AWS, joissa voit helposti pyörittää laskentaesiintymiä määrittämällä ilmentymän yksityiskohdat määritystiedostossa ja hyödyntämällä työkaluja, kuten Terraform, resurssien käyttöönottamiseksi.

Esimerkiksi Amazon AWS tarjoaa sovellusliittymiä, joiden avulla käyttäjät voivat olla ohjelmallisesti vuorovaikutuksessa Cloud-alustan kanssa komentoriviltä. Tämä helpottaa resurssien nopeaa käyttöönottoa poistamalla manuaaliset prosessit ja löysyys. Yksinkertaisesti sanottuna IaC tekee enemmän työtä lyhyessä ajassa.

Mikropalveluarkkitehtuurissa yksi sovellus on erilaisten pienempien löyhästi kytkettyjen palvelujen integrointi tai yhdistäminen. Jokainen palvelu toimii itsenäisesti ja kommunikoi muiden sovellusten kanssa HTTP-pohjaisten sovellusliittymien avulla. Mikropalvelut voidaan ottaa käyttöön palveluryhmänä tai yhtenä palveluna

Mikropalveluarkkitehtuuri eroaa paljon perinteisestä monoliittisesta arkkitehtuurista. Perinteisessä arkkitehtuurissa sovellukset ovat yksitasoisia ja kaikki komponentit, mukaan lukien koodi ja käyttöliittymä, on niputettu yhdeksi ohjelmaksi.

Mikropalvelut helpottavat itsenäistä käyttöönottoa ja resurssien hallintaa. Ne varmistavat myös korkean käytettävyyden estämällä yhden vikakohdan. kun yksi sovellus kaatuu, loput jatkavat toimintaansa.

DevOps-mallin edut

Tarkasteltuamme DevOpsin parhaita käytäntöjä, keskitytään nyt DevOps-mallin käyttöönoton etuihin.

Kehitystiimien välinen yhteistyö merkitsee yhteistä vastuullisuutta, mikä viime kädessä lisää tuottavuutta ja edistää tiimien sitoutumista.

Yhteistyön avulla tiimit voivat myös helposti korjata koodia jokaisessa vaiheessa ennen kuin pääsevät viimeiseen vaiheeseen. Tämä tuottaa korkealaatuisia ja markkinavalmiita ohjelmistoja.

Sovellusten käyttöönotto on virtaviivaisempaa ja paljon nopeampaa DevOpsin tarjoamien automaatiotyökalujen (kuten Ansible, Chef ja Puppet) ja edistyneen jatkuvan integraation (CI) ansiosta.

Koska tuotetieto on hajallaan eri osastojen kesken, tuotteella on selkeä tavoite ja visio, mikä johtaa parempaan päätöksentekoon jokaisessa kehitysvaiheessa.

Vanhentunut käsitys siitä, että kehitys- ja käyttötiimien on toimittava ikuisesti erikseen, on vanhentunut ja puutteellinen. Siled-filosofia saattaa edelleen olla elossa joillakin toimialoilla, mutta tämä on johtanut räikeisiin tehottomuuteen matkan varrella.

DevOps pyrkii integroimaan kehitys- ja käyttötiimejä ja edistämään kulttuurista muutosta vanhasta siiloissa työskentelystä rinnakkaiseen työskentelyyn vähentääkseen koodivirheitä, parantaakseen ohjelmistojen laatua, nopeuttaakseen toimitusaikoja ja lisätäkseen yleistä tuottavuutta. Loppujen lopuksi loppukäyttäjä saa korkealaatuisen tuotteen oikea-aikaisesti.