Devops on nyt tärkeä monissa teknologiaorganisaatioissa kahden näennäisesti vastakkaisen tehtävän ja kulttuurin takia, joiden on tultava yhteen:
- Ketterät kehitystiimit etenevät nopeasti vastaamaan liiketoiminnan vaatimuksiin ja toteuttamaan sovellusten muutoksia.
- Operatiiviset ryhmät työskentelevät ahkerasti pitääkseen järjestelmät toimivina, varmistaakseen, että tietotekniikkaympäristöt ovat turvallisia, ja hallitsemaan laskentaresursseja.
Ketterät ryhmät pitävät operatiivisia joukkueita usein hitaina ja jäykkinä, kun taas järjestelmäinsinöörit pitävät ketteriä kehittäjiä operatiivisten tarpeiden tukemattomina ja huolimattomina, kun sovellusten käyttöönotto aiheuttaa tuotanto-ongelmia.
Nämä ovat yleistyksiä, mutta näillä kahdella tieteenalalla on usein erilaiset motivaatiot, terminologia ja työkalut - ja tämä epäsuhta voi aiheuttaa liiketoimintaan liittyviä kysymyksiä. Esimerkiksi, kun startupit kasvavat, heidän on kehitettävä toimintamenetelmät vakauden varmistamiseksi samalla, kun ne vaikuttavat minimaalisesti kehityksen nopeuteen ja ketteryyteen. Suurille yrityksille heidän on löydettävä tapoja toimittaa asiakaslähtöisiä sovelluksia ja sisäisiä työnkulun parannuksia nopeammin vaarantamatta luotettavuutta tai pudottamasta vaatimuksia.
Devops pyrkii ratkaisemaan nämä ristiriidat kulttuurin, toimintaperiaatteiden ja uusien parhaiden käytäntöjen joukon avulla, jotka mahdollistavat sovellusten käyttöönoton nopeuden ja vakauden, mikä johtaa vähemmän konflikteihin ja kompromisseihin. Tämä tapahtuu suurelta osin tarjoamalla käytäntöjä, jotka automatisoivat toimintavaiheet ja standardoivat kokoonpanot:
- Kehitystiimeille nämä käytännöt standardoivat ja automatisoivat vaiheet koodin kehittämisestä testaamiseen, suojaamiseen ja käyttämiseen useissa ympäristöissä.
- Toiminnoissa käytäntöjen avulla automatisoidaan infrastruktuurin määritys ja käyttöönotto, useiden verkkotunnusten seuranta ja tuotantokysymysten nopeampi ratkaisu.
Devops-käytäntöjä ovat:
- Versiohallinta- ja haaroitusstrategiat.
- Jatkuva integrointi ja jatkuva toimitus (CI / CD) -putket.
- Säiliöt, jotka standardoivat ja eristävät sovelluksen ajonaikaisia ympäristöjä.
- Infrastructure as code (IAC), joka mahdollistaa komentosarjat infrastruktuurikerroksen.
- Devops-putkistojen ja käynnissä olevien sovellusten kunnon seuranta.
Devops alkaa käytännöistä ja työkaluista, joita käytetään ohjelmistojen julkaisemiseen ympäristöjen laskemiseksi perusrakenteilla, jotka ovat olleet käytössä vuosikymmenien ajan. Ne sisältävät versionhallinnan koodimuutosten hallitsemiseksi kehittäjäryhmässä, koodipohjan haaroittaminen erilaisten kehitystoimintojen tukemiseksi ja ohjelmistoversioiden koodaaminen ennen niiden työntämistä eri ympäristöihin.
Tärkeimmät erot devops-tiimeissä on se, että työkaluja on helpompi käyttää ja integroida paremmin muihin tekniikoihin, jotka automatisoivat sovellusten rakentamista ja käyttöönottoa. On myös standardisoituja haaroitus- ja koodin yhdistämisstrategioita, joita on helpompi hallita nykyaikaisilla versionhallintajärjestelmillä.
Esimerkiksi monet organisaatiot käyttävät Git-ohjelmistoa (mukaan lukien GitHub- ja BitBucket-versiot) ja muita versionhallintatyökaluja, jotka tarjoavat useita asiakassovelluksia, sovellusliittymiä integrointiin ja komentorivityökaluja useamman tai monimutkaisemman prosessin hallintaan. Nykyään useimmat kehittäjät ovat käyttäneet projektissaan ainakin yhtä versionhallintatekniikkaa, joten standardien toteuttaminen ei ole niin vaikeaa kuin ennen.
Näitä työkaluja käyttävät organisaatiot voivat ottaa käyttöön haarautumisstrategiat, kuten Gitflow, jotka standardoivat haarat tuotannossa, testauksessa ja kehityksessä sekä perustavat menettelyt uusien ominaisuuksien tai tuotantomerkkien kehittämiseksi. Nämä haarautumisstrategiat antavat tiimien tehdä yhteistyötä erityyppisten kehitystarpeiden kanssa ja ottavat käyttöön vain testatun ja käyttöönotettavan koodin tuotannon aloille. Tämän jälkeen joukkueet merkitsevät versiotunnisteiden avulla kaikki lähdekoodiversiot ja muut ohjelmistojulkaisuun kuuluvat tiedostot.
Suurin osa organisaatioista, jotka tarvitsevat käyttäjätukea tuotantojulkaisujen jälkeen, ja muut, jotka kehittävät varhaisessa vaiheessa devops-käytäntöjään, noudattavat usein perinteisiä julkaisujen hallinnan käytäntöjä, jotka tukevat rakenteita, kuten suuria ja pieniä julkaisuja. Kehittyneemmät tiimit, jotka kehittävät vähemmän käyttäjän tukea tarvitsevia sovelluksia, voivat harjoittaa jatkuvaa käyttöönottoa, kun on automaatiota, joka integroi jatkuvasti ja toimittaa koodimuutokset tuotantoympäristöihin.
Jotta useammat julkaisut mahdollistaisivat, tiimit haluavat automatisoida vaiheet koodin tarkistamisesta täysin testattujen sovellusten toimittamiseen kohdelaskentaympäristöihin. Jatkuva integraatio (CI) on automaatio kaikkien ohjelmistokomponenttien rakentamiseksi ja integroimiseksi siten, että ne ovat käyttöönotettavassa paketissa. Jatkuvan käyttöönoton (CD) työkalut hallitsevat ympäristökohtaisia muuttujia ja automatisoivat sovellusten siirtämisen kehitykseen, testaukseen, tuotantoon ja muihin tietojenkäsittelyympäristöihin. Nämä työkalut muodostavat yhdessä CI / CD-putken.
Jotta CI / CD olisi tehokas automaatioprosessi, jatkuvaa testausta on toteutettava valmisteilla sen varmistamiseksi, että uusi koodi ei aiheuta vikoja tai muita ongelmia. Jatkuvassa integraatioputkessa toteutetut yksikkötestit varmistavat, että annettu koodi ei riko olemassa olevia yksikötestejä. Muut testit, jotka etsivät kooditason tietoturvaongelmia ja koodirakennetta, voidaan toteuttaa myös integraatiovaiheessa. Ajonaikaisia ympäristöjä vaativat automatisoidut toiminnot ja suorituskyky automatisoidaan usein osana jatkuvaa toimitusputkistoa.
Tämä automaatio ajaa monia hyödyllisiä käyttäytymis- ja käytäntömuutoksia, joiden avulla tiimit voivat tehdä muutoksia useammin ja turvallisemmin. Se ajaa joukkueita kirjautumaan sisään ja testaamaan koodia useammin, mikä antaa vikojen löytämisen ja korjaamisen nopeammin. Manuaaliset käyttöönottomenettelyt ovat alttiita virheille, jotka automaatio suurelta osin eliminoi. Automaatio vie myös suurimman osan yleiskustannuksista uusien ominaisuuksien tuomisessa käyttäjille, jolloin tiimit saavat käyttöönsä useammin.
Jos CI / CD tarjoaa automaation toimittaa sovelluksia, kontit ovat sovelluksen toimintaympäristön pakkaus. Kehittäjät voivat määrittää käyttöjärjestelmän, sovellusvaatimukset ja kokoonpanovaatimukset säilönä sovellusten suorittamiseen erillisessä kerroksessa, joka jakaa isäntänsä käyttöjärjestelmän. Docker ja Kubernetes ovat konttitekniikoita, jotka auttavat kehittäjiä määrittelemään sovellusympäristönsä johdonmukaisella tavalla.
CI / CD-putkistoilla, jotka integroivat ja ottavat käyttöön koodin, sekä standardoiduilla säiliöillä, jotka eristävät kunkin sovelluksen tietotekniikkatarpeet, kehittäjillä on työkalut valmistaa sovelluspalveluja ilman paljon lisäkustannuksia. Kehitystiimeillä on sitten suuremmat mahdollisuudet muuntaa liiketoiminnan vaatimukset mikropalveluiksi, jotka voidaan ottaa käyttöön, skaalata ja hyödyntää useisiin liiketoiminnan tarpeisiin.
Kun koodien integroinnin ja toimituksen automatisointi ja sovellusten säilöinti ohjaavat sovellusten toimitusta, seuraavat devops-käytännöt auttavat automatisoimaan ja standardoimaan infrastruktuurin ja pilvipalvelut.
Infrastruktuurin automatisointi ja hallinta oli aiemmin vaikeaa. Kun arkkitehtuuri oli valittu, operatiiviset insinöörit kävivät useissa infrastruktuurikomponenteissa rakentamaan ja konfiguroimaan niitä vaatimusten mukaisesti. Näiden arkkitehtuurien kaappaamiseen käytetyt kokoonpano- ja omaisuudenhallintatyökalut vaativat automaattisten ja manuaalisten vaiheiden yhdistelmää ja olivat usein vanhentuneita tai puuttuivat kriittisiä tietoja. Laskentaympäristöt olivat myös jäykkiä, ja vaikka skaalausympäristöjen automatisoimiseksi oli joitain työkaluja, ne olivat usein eristetty tietyn infrastruktuurityypin kanssa, vaativat erilaisia taitoja automaation toteuttamiseksi ja niillä oli pääsy vain osaan operatiivisia tietoja sen määrittämiseksi, onko ja miten skaalata.
Nykypäivän pilviympäristöt tarjoavat käyttöliittymiä, jotka yksinkertaistavat insinöörien työtä. Suunnittelijat voivat käyttää näitä työkaluja virtuaalisten yksityisverkkojen määrittämiseen, suojausryhmien määritykseen ja sitten laskentatoimen, tallennustilan ja muiden tarvittavien palveluiden käynnistämiseen.
Mutta devops-joukkueet ottavat tämän askeleen pidemmälle. Verkkorajapintojen käyttämisen ja tietokoneresurssien manuaalisen määrittelemisen sijaan ne automatisoivat prosessin koodilla. Infrastructure as code (IaC) -työkalut antavat operatiivisten insinöörien komentosarjan ja automatisoivat infrastruktuurin asennuksen ja hallinnan. Näihin komentosarjoihin voidaan upottaa myös kokoonpanot, jotka mahdollistavat skaalaamisen ylös ja alas ympäristöissä. Chef, Puppet, Ansible ja Salt ovat neljä kilpailevaa tekniikkaa, jotka auttavat toteuttamaan operatiivisia tiimejä toteuttamaan IaC: tä.
Valmistusprosessi on vain yhtä hyvä kuin kyky seurata, hälyttää ja toipua ongelmista. Sama pätee devopien seurantaan ja sovellusten ja palveluiden käyttökokemukseen. Kun organisaatiot investoivat automaatioon, konttien jakamiseen, standardointiin ja sovellusten käyttöönottoon, rinnakkainvestointi seurantaan on paras käytäntö.
Ajattele seurantaa useilla tasoilla. Alimmalla tasolla on infrastruktuurin seuranta, joka mahdollistaa tunnistamisen ja vastaukset, kun laskentaresurssit eivät ole terveitä tai heikosti menestyviä. Pilviympäristöt tarjoavat nykyään valmiuksia seurata, hälyttää ja käyttää joustavia pilviominaisuuksia infrastruktuuriongelmiin vastaamiseksi.
Seuraava kerros koostuu työkaluista, joilla seurataan ja siepataan Devops-automaation ympärillä olevia tietoja. Nämä työkalut ovat kriittisempiä, kun kehittäjien ja käyttöönotettavien palvelujen määrä kasvaa. Nämä työkalut tarjoavat ilmoituksia koontivirheestä ja tarkastustyökaluja ongelmien diagnosoimiseksi.
Viimeisenä on työkaluja, jotka seuraavat sovelluksen käyttöaikaa, suorituskykyä ja muita ajonaikaisia mittareita. Nämä valvontatyökalut testaavat usein sovellusliittymiä ja suorittavat myös täydelliset selaintestit joko yksittäisille päätepisteille tai monivaiheisille tapahtumille. Nämä näytöt ovat etulinjan puolustus varoittaakseen palvelijatiimejä, kun sovellusliittymät tai sovellukset toimivat hyväksyttävän palvelutason ulkopuolella.
Devops-käytäntöjä on monia, ja ne kaikki vievät aikaa kypsymiseen ja integroitumiseen. Niiden toteuttamiseen ei ole määrättyä järjestystä tai kovia suosituksia siitä, kuinka paljon automaatioon investoidaan.
Silti organisaatioiden tulisi ensin pyrkiä sovittamaan kulttuuri ja ajattelutapa devops-periaatteiden ympärille ja sitten tunnistamaan, mitkä käytännöt sopivat parhaiten liiketoiminnan tarpeisiin. Esimerkiksi organisaatiot, joiden sovellusten suorituskyky on jo heikko, voivat päättää ottaa käyttöön ensin valvonnan, jotta ongelmat voidaan ratkaista nopeammin ja tunnistaa perussyyt helpommin. Muut organisaatiot, jotka aloittavat pilvipalvelujen siirron, voivat päättää käyttää infrastruktuuria koodina, kun taas vakiomuotoiset sovelluskehitysarkkitehtuurit perustavat organisaatiot voivat sijoittaa CI / CD-putkiin.
Teknologien tulisi pitää mielessä, että automaation toteuttaminen maksaa, ja että kaikki organisaatiot eivät vaadi jatkuvaa käyttöönottoa. Paras käytäntö on varmistaa, että yritys täyttää ensin liiketoimintatarpeet ja sovittaa devops-automaation usein toistettaville alueille, joilla manuaaliset toimet ovat alttiita virheille.
