DevOps-menetelmä: DevOps-menetelmä: Menestyksen periaatteet | StackPulse

DevOps-menetelmässä yhdistyvät kaksi alaa – ohjelmistokehitys ja tietotekniikan (IT) toiminta. DevOps-menetelmän päätavoite on nopea tuotejulkaisu, joka saavutetaan automaation, viestinnän ja jatkuvan työnkulun avulla.

DevOps-menetelmän tärkeimpiä perusperiaatteita ovat ristiinkoulutus, yhteistyö, jatkuva parantaminen, vastuullisuus, läpinäkyvyys ja automaatio. DevOps-tiimit soveltavat näitä periaatteita luodessaan DevOps-prosessia, joka sisältää tyypillisesti seitsemän vaihetta-suunnittelu, koodaus, rakentaminen, testaaminen, toimittaminen, käyttöönotto ja seuranta.

Tässä artikkelissa opit:

• Mikä on DevOps-menetelmä?
• 6 keskeistä DevOps-periaatetta
• Mikä on DevOps-prosessi?
• DevOps vs. Ketterä: vertailu

Mikä on DevOps-menetelmä?

DevOps-menetelmä on joukko käytäntöjä, jotka edellyttävät kehitys- ja toimintatiimien yhteistyötä ohjelmistokehityksen elinkaaren (SDLC) aikana. Se sisältää ketteriä käytäntöjä ja keskittyy tiimisiilojen purkamiseen, manuaalisten tehtävien automatisointiin ja tuottavuuden lisäämiseen jatkuvan palautteen avulla.

Käytettäessä DevOps-tiimejä organisaatiot ottavat usein käyttöön useita käytäntöjä ja työkaluja samanaikaisesti. Näitä ovat:

• Jatkuva integrointi / jatkuva käyttöönotto (CI/CD) – joukko prosesseja, jotka hyödyntävät automaatiota tehokkuuden, laadun ja nopeuden parantamiseen ohjelmistokehityksen elinkaaressa. CI sisältää usein toistuvia, pieniä muutoksia koodipohjiin, jotka testataan ja integroidaan mahdollisimman pian. CD:hen kuuluu uuden koodin julkaiseminen usein tuotantoon ilman manuaalisia päivityksiä tai korjauksia.
• Pilvipohjaiset putkilinjat-putkilinjat ovat työkaluketjuja, joita käytetään CI/CD:n kaltaisten työnkulkujen suorittamiseen. Usein nämä työkaluketjut rakentuvat pilvessä isännöidyistä palveluista ja resursseista, mikä mahdollistaa pilvinatiivisen kehityksen ja suuremman tuen hajautetuille tiimeille.
• Mikropalvelut-arkkitehtuuri, jota käytetään pilvinatiivisten sovellusten kanssa suuremman skaalautuvuuden, saatavuuden ja joustavuuden mahdollistamiseksi. Mikropalveluiden avulla tiimit voivat rakentaa sovelluksia ja putkistoja, jotka ovat löyhästi kytkettyjä ja joita on helppo muokata tai päivittää.
• Infrastructure as code (IaaC)-menetelmä, jonka avulla tiimit voivat tarjota, konfiguroida ja hallita infrastruktuuria ohjelmistojen ja koodattujen määrittelytiedostojen avulla. Tämä menetelmä mahdollistaa monien infrastruktuuritehtävien automatisoinnin ja tukee massiivisia käyttöönottoja ilman, että tiimin resursseja tarvitaan merkittävästi lisää.

DevOpsin keskeiset periaatteet

Kun luot DevOps-menetelmää ja toimitaan sen mukaisesti, on olemassa useita keskeisiä periaatteita, joiden omaksumista kannattaa harkita.

Ristiinkoulutus

DevOpsissa pyritään ristiinkouluttamaan tiimin jäseniä kaikissa SDLC:n prosesseissa. Tämä ei tarkoita, että kaikkien tiimin jäsenten on oltava yhtä päteviä, mutta kaikkien tulisi tuntea käytetyt prosessit, työkalut ja taidot.

Kun tiimin jäsenten osaaminen on tällä tavoin päällekkäistä, tiimin jäsenten on helpompi kommunikoida. Se edistää uudenlaisia ratkaisuja, koska jäsenet ovat vähemmän ”loukussa” odotuksissa siitä, miten asiat pitäisi tehdä. Ristikoulutus voi myös ehkäistä toisiin tukeutumisesta johtuvia pullonkauloja, mikä nopeuttaa tuottavuutta.

Yhteistyö

Yhteistyö ja sen edellyttämä viestintä ovat DevOpsin keskeisiä elementtejä. Tämä menetelmä luottaa siihen, että tiimin jäsenet työskentelevät sujuvasti yhdessä ja reagoivat palautteeseen, kun jokin asia ei toimi odotetulla tavalla. Jos tiimin jäsenet eivät pysty tekemään yhteistyötä, työ siiloutuu ja tuottavuus rajoittuu vaiheiden suorittamiseen.

Jatkuva parantaminen

DevOps käyttää iteratiivista prosessia, jossa pieniä muutoksia hiotaan, kunnes muutos läpäisee tarkastuskynnykset. Heti kun muutos on hyväksytty, aloitetaan seuraava. Tätä jatkuvaa parantamista sovelletaan DevOpsin kaikkiin osa-alueisiin, kuten tuotekehitykseen, putkiston suorituskykyyn ja prosessien tehokkuuteen.

Vastuullisuus

DevOps-malli edellyttää vastuullisuutta kaikista tehtävistä – olivatpa ne sitten kehitystehtäviä tai operatiivisia tehtäviä – ja molempien tulisi olla yhtä lailla kaikkien organisaation jäsenten vastuulla. Tämä poistaa perinteisen ajattelutavan ”jonkun muun ongelma” ja auttaa varmistamaan, että tiimit ovat huolellisia toimissaan, liittyivätpä ne sitten kehitykseen tai toimintaan. Se auttaa myös rakentamaan ja lujittamaan suhteita tiimin sisällä, koska kaikki jäsenet odottavat yhtä paljon työtä ja vastuuta.

Transparenssi

Prosessien, kokoonpanojen, työkalujen ja odotusten läpinäkyvyys ovat kaikki tärkeitä DevOpsissa. Ilman läpinäkyvyyttä tiimit eivät voi tehdä tehokasta yhteistyötä, ja ”me vastaan he” -tunnelma säilyy. Tämä estää viestintää ja vaikeuttaa toisten pitämistä vastuullisina. Avoimuuden ansiosta kaikki tiimin jäsenet voivat auttaa tunnistamaan esiin tulevat ongelmat ja ehdottaa parannuksia kokonaisuuden kannalta.

Automaatio

DevOps Automaatio auttaa tiimejä virtaviivaistamaan ja standardoimaan työtä. Se auttaa myös luomaan läpinäkyvyyttä, koska se edellyttää, että menettelyt määritellään ja dokumentoidaan. Automatisoimalla tylsiä tai aikaa vieviä tehtäviä DevOps-tiimit voivat keskittyä korkeamman tason työhön. Tämä keskittyminen voi parantaa laatua ja rohkaista innovointiin.

DevOps-prosessi

Kaikkakin DevOps-prosessin yksittäiset menettelyt voivat vaihdella, kokonaisprosessi noudattaa melko yhtenäisiä vaiheita. Nämä vaiheet tapahtuvat syklinä, ja ne voivat muuttua tai palata edellisiin vaiheisiin palautesilmukoista riippuen. DevOpsin elinkaari sisältää tyypillisesti seuraavat vaiheet:

• Suunnittele – projektin, sprintin/eritelmän tai päivän alussa työ suunnitellaan ja priorisoidaan. Näin varmistetaan, että kaikki tiimin jäsenet ymmärtävät nykyiset tavoitteet, ja määritellään, mitä työtä odotetaan.
• Koodi-kehittäjät luovat ja toimittavat koodimuutoksia tai -lisäyksiä, jotka täyttävät nykyiselle iteraatiolle määritellyt tehtävät. Nämä perustuvat master-koodipohjaan, johon kaikilla kehittäjillä on pääsy. Tähän vaiheeseen kuuluu myös koodin tarkistus ja tarvittavat selvennykset tai mukautukset. Jos toimitettu koodi ei läpäise testausta, se palautetaan tähän vaiheeseen muokattavaksi.
• Build – toimitettu koodi käännetään, yksikkötestataan ja pakataan. Tämä on yleensä ensimmäinen automaattinen vaihe CI/CD-putkessa. Jos build epäonnistuu, kehittäjälle lähetetään palaute ja lähetetty muutos hylätään. Jos build onnistuu, se siirretään jatkotestaukseen.
• Testit – onnistuneet buildit läpäisevät sarjan testejä, joilla varmistetaan toiminnallisuus, laatu ja usein myös tietoturva. Ihannetapauksessa nopeimmat tai kriittisimmät testit suoritetaan ensin. Tällä tavoin, jos testi epäonnistuu, alkuperäiseen koodimuutokseen voidaan palauttaa palaute mahdollisimman pian, eikä vaivaa mene hukkaan. Jos kaikki testit läpäisevät, rakennelma siirretään toimitukseen ja muutokset yhdistetään pääkoodihaaraan. Näin varmistetaan, että kaikki kehittäjät jatkavat työskentelyä samasta lähtökohdasta käsin.
• Deliver – viimeisin läpäissyt build säilytetään ja pidetään käyttöönotossa.
• Deploy-rakennelma voidaan ottaa käyttöön testiympäristöön lisätestausta, kuten käyttäjän hyväksyntää, varten. Tai se voidaan toimittaa staging- tai tuotantoympäristöön julkaisua varten.
• Seuranta-julkaisun jälkeen versioita seurataan, jotta havaitaan mahdolliset huomaamatta jääneet ongelmat ja kerätään käyttötietoja, joita voidaan soveltaa tuleviin parannuksiin. Voit oppia lisää DevOps-seurannasta artikkelissamme: DevOps Monitoring: The Abridged Guide.

DevOps vs. Agile: Mikä on ero ja miten ne liittyvät toisiinsa?

Kun puhutaan DevOps-menetelmästä, se liitetään usein Agileen. Tämä on järkevää, kun otetaan huomioon, että monet DevOps-tiimit käyttävät ketteriä käytäntöjä. Lisäksi molemmat menetelmät keskittyvät nopeuden, tehokkuuden ja laadun parantamiseen. Tästä huolimatta metodologiat eroavat toisistaan, eikä toinen välttämättä edellytä toista.

Viestintä

Ketterissä menetelmissä keskitytään tiimien väliseen viestintään ja asiakkaiden ottamiseen mukaan koko projektiprosessiin. Samoin suurin osa palautteesta ketterissä prosesseissa tulee asiakkailta.

DevOpsissa viestintä keskittyy kehittäjiin ja operaatioihin. Asiakaspalautteella on merkitystä suunnittelu- ja toimitusvaiheissa, mutta sitä ei yleensä ole välivaiheissa. Sen sijaan tiimit luottavat työn ohjaamisessa työkalujen ja muiden tiimin jäsenten palautteeseen.

Tiimirakenne

Kummassakin Agile- ja DevOps-tiimissä priorisoidaan taitojen jakamista ja ristiinkoulutusta. DevOpsilla on kuitenkin taipumus soveltaa näitä taitoja enemmän viestintään ja yhteistyöhön kuin vastuullisuuteen. DevOps-tiimeissä kehittäjät vastaavat koodin luomisesta, ja testaus- ja käyttötiimit (joita kutsutaan DevOps-tiimeiksi) vastaavat putkenhallinnasta, ympäristön konfiguroinnista ja käyttöönotosta.

Ketterissä tiimeissä sen sijaan vastuualueiden väliset rajat hämärtyvät usein. Ketterässä tiimissä kaikkia rohkaistaan tarttumaan kaikkiin tarvittaviin tehtäviin, ja roolit ovat vähemmän erillisiä. Tämän seurauksena Agile toimii yleensä paremmin pienemmissä tiimeissä, kun taas DevOps pystyy paremmin tarjoamaan suurempien tiimien tarvitseman rakenteen.

Aikataulutus

Agile-menetelmissä noudatetaan sprinttiä tai ajallisesti rajoitettua iteraatiota. Useita sprinttejä suoritetaan, kunnes projekti on valmis, ja jokaisessa sprintissä määritellään erityiset tehtävät ja tavoitteet. Sprinttejä ja odotettua työtä mukautetaan usein tiimin tuotoksen mukaan.

DevOps-toteutuksissa tavoitteena on, että tuote on aina toimitettavissa. Tiimit voivat kuitenkin käyttää sprinttejä tai iteraatioita määrittelemään työn, jonka odotetaan sisältyvän tiettyyn julkaisuun. Lisäksi DevOps-tiimejä pidetään usein kiinni tarkemmista määräajoista ja vertailuarvoista, ja niillä on vähemmän joustovaraa määritellä, milloin tuote on valmis.

Automaatio DevOps-menetelmää varten: Continuous Operations, Monitoring, and Feedback With StackPulse

Yritystemme muuttuessa yhä digitaalisemmiksi, niitä mahdollistavien ohjelmistopalveluiden luotettavuudesta tulee liiketoimintakriittinen kysymys. Jokaisessa ohjelmistojärjestelmässä, olipa se kuinka hyvin suunniteltu tahansa, on tuotantohälytyksiä. Nämä ovat joko paikallisia ongelmia, joilla on vain vähän tai ei lainkaan vaikutusta loppukäyttäjiin, tai kriittisiä ongelmia, jotka vaikuttavat palvelun saatavuuteen käyttäjille.

Kummassakin tapauksessa asianomaisten omistajien tulisi tutkia, analysoida ja tarvittaessa korjata ongelmat. Ilman asianmukaista automaatiota tapahtumien ja hälytysten suuri määrä johtaa useimmissa organisaatioissa:

• Negatiivisiin tuottavuusvaikutuksiin R&D- ja DevOps-tiimeissä
• ”Hälytysväsymykseen” omistajilla ja tukitiimeillä
• Tuotantopalveluiden pidempiin seisokkiaikoihin.

StackPulse on automatisointialusta DevOps- syklin operaatio-, monitorointi- ja palautteenantovaiheisiin. Sen avulla DevOps- ja suunnittelutiimit voivat määritellä koodattuja pelikirjoja näitä prosesseja varten. Näin organisaatiosi voi automatisoida prosesseja toistettavalla ja mitattavissa olevalla tavalla ja käynnistää ne niin usein kuin on tarpeen ilman ylimääräistä manuaalista työtä.

Saa varhainen pääsy StackPulseen ja ole ensimmäisten joukossa kokeilemassa DevOps / SRE-automaatioalustamme.