Monet teistä saattavat olla tietoisia kaikista siihen liittyvistä teorioista . Mutta tiedätkö kuinka DevOps-periaatteet pannaan täytäntöön tosielämässä? Tässä blogissa keskustelen DevOps Real Time -skenaarioista, jotka auttavat sinua saamaan lyhyen käsityksen siitä, miten asiat toimivat reaaliajassa.
Viitteet, jotka käsittelen tässäDevOpsin reaaliaikaiset skenaariot -artikkeliovat:
- Mikä on DevOps?
- DevOpsin ratkaisemat ongelmat
- CI (jatkuva integrointi) -skenaariot
- CT (jatkuva testaus) -skenaariot
- CD (jatkuva toimitus) -skenaariot
- DevOps-dataskenaariot
Aloitetaan siis ensimmäisestä aiheesta.
Mikä on DevOps?
DevOps on ohjelmistokehitystapa, johon sisältyy ohjelmiston jatkuva kehittäminen, jatkuva testaus, jatkuva integrointi, jatkuva käyttöönotto ja jatkuva valvonta sen koko elinkaaren ajan. Nämä toiminnot ovat mahdollisia vain DevOpsissa, ei ketterässä tai vesiputouksessa. Siksi Facebook ja muut huippuyritykset ovat valinneet DevOpsin etenemistavoitteeksi liiketoimintatavoitteidensa saavuttamiseksi.DevOpsia suositaan pääasiassa korkealaatuisten ohjelmistojen kehittämiseksi lyhyemmissä kehitysjaksoissa, mikä lisää asiakastyytyväisyyttä.
Tämän seuraavassa osassaDevOps Reaaliaikaiset skenaariot -artikkelissa tarkastellaan DevOpsin ratkaisemia ongelmia.
DevOpsin ratkaisemat ongelmat
1. Toimita arvoa asiakkaille
- DevOps minimoi ajan se vie arvoa asiakkaille. Syklin aika kehittäjän tarinan / tehtävän suorittamisesta tuotantoon vähenee merkittävästi, jolloin arvo voidaan toteuttaa mahdollisimman nopeasti.
Tärkein arvo DevOpsin kautta on, että se antaa IT-organisaatioille mahdollisuuden keskittyä ydinliiketoimintaansa . Poistamalla rajoitukset arvovirrassa ja automatisoimalla käyttöönottoputket, tiimit voivat keskittyä toimintaan. Tämä auttaa luomaan asiakasarvoa pikemminkin kuin vain siirtämään bittiä ja tavuja. Nämä toiminnot lisäävät yrityksen kestävää kilpailuetua ja parantavat liiketoiminnan tuloksia.
2. Lyhennetty jaksoaika
Sisäisesti DevOps on ainoa tapa saavuttaa ketteryys toimittaa suojattua koodia oivalluksilla. On tärkeää, että sinulla on portit ja hyvin muotoiltu DevOps-prosessi. Kun toimitat uuden version, se voi toimia rinnakkain nykyisen version kanssa. Voit myös verrata mittareita saavuttaaksesi haluamasi sovellus- ja suorituskykymittareihin.
kuinka asettaa luokkatie linuxissa
DevOps ajaa kehitystiimejä kohti jatkuva parantaminen ja nopeammat vapautussyklit . Jos tämä tehdään hyvin, tämä iteratiivinen prosessi antaa enemmän keskittyä ajan mittaan asioihin, joilla on todella merkitystä. Kuten asiat, jotka luovat käyttäjille hyviä kokemuksia - ja vähemmän aikaa työkalujen, prosessien ja tekniikan hallintaan.
3. Aika markkinoille
Tärkein ratkaistava ongelma on prosessin monimutkaisuuden vähentäminen. Tämä myötävaikuttaa merkittävästi liiketoimintamme menestykseen lyhentämällä markkinoillemme kuluvaa aikaa, antamalla meille nopean palautteen ominaisuuksista ja vastaamalla paremmin asiakkaidemme tarpeisiin.
4. Ongelmanratkaisu
DevOps-onnistuneen toteutuksen suurin arvo on parempi luottamus toimitukseen, näkyvyys ja jäljitettävyys tapahtumiin, joten voit ratkaista ongelmat nopeammin.
Toinen tärkeä DevOps-etu on, ettei tuhlaa aikaa. Organisaation ihmisten ja resurssien tasaaminen mahdollistaa nopean käyttöönoton ja päivittämisen. Tämä antaa DevOps-ohjelmille mahdollisuuden korjata ongelmat ennen kuin ne muuttuvat katastrofeiksi.DevOps luo läpinäkyvyyden kulttuurin, joka edistää keskittymistä ja yhteistyötä kehitys-, operaatio- ja tietoturvaryhmien välillä.
CI (jatkuva integrointi)DevOpsin reaaliaikaiset skenaariot
1. Yksilöt saattavat nähdä jatkuvan integraation haitalliseksi
Kehitystiimin jäsenillä on erilaiset tehtävät, vastuut ja prioriteetit. On mahdollista, että tuotepäällikön ensisijainen tavoite saattaa olla uusien ominaisuuksien käynnistäminen, projektipäällikön on varmistettava, että heidän tiiminsä noudattaa määräaikaa. Ohjelmoijat saattavat ajatella, että jos he pysähtyvät korjaamaan pienen virheen joka kerta, se hidastaa heitä. He saattavat kokea, että rakennuksen pitäminen puhtaana on ylimääräinen taakka heille, eivätkä he hyöty heidän ylimääräisistä ponnisteluistaan. Tämä voi vaarantaa sopeutumisprosessin.
Tämän voittamiseksi:
Ensinnäkin, varmista, että koko tiimisi on aluksella, ennen kuin otat jatkuvan integraation käyttöön.
CTO: n ja ryhmänjohtajien on autettava tiimin jäseniä ymmärtämään jatkuvan integraation kustannukset ja edut.
Korosta, mitä ja milloin koodereille on hyötyä omistautumalla toiselle työmenetelmälle, joka vaatii hieman enemmän avoimuutta ja joustavuutta.
2. CI: n integrointi olemassa olevaan kehitysvirtaan
CI: n hyväksyminen edellyttää väistämättä muutoksia joihinkin kehitystyön kulkuisi. On mahdollista, että kehittäjät eivät ehkä korjaa työnkulkua, jos se ei ole rikki. Tämä on mahdollista lähinnä, jos tiimilläsi on suurempi rutiini nykyisen työnkulun suorittamisessa.
Jos haluat muuttaa työnkulkua, sinun on tehtävä se erittäin varovasti. Muuten se voi vaarantaa kehitystiimin tuottavuuden ja myös tuotteen laadun. Ilman johdon riittävää tukea kehitystiimi saattaa olla hieman haluttomia suorittamaan tehtävää, johon liittyy tällaisia riskejä.
Tämän voittamiseksi:
Sinun on varmistettava, että annat riittävästi aikaa tiimillesi uuden työnkulun kehittämiseen. Tämä tehdään joustavan jatkuvan integrointiratkaisun valitsemiseksi, joka tukee heidän uutta työnkulkuaan.
Varmista myös, että yrityksellä on selkänsä, vaikka asiat eivät ehkä menisi kovin sujuvasti alussa.
3. Palautetaan entisiin testaustottumuksiin
Jatkuvan integraation omaksumisen välitön vaikutus on, että tiimisi testaa useammin. Joten useampi testi vaatii enemmän testitapauksia, ja testitapausten kirjoittaminen voi olla aikaa vievää. Kehittäjien on siis usein jaettava aika virheiden korjaamisen ja testitapausten kirjoittamisen välillä.
Väliaikaisesti kehittäjät saattavat pystyä säästämään aikaa manuaalisesti testaamalla, mutta se saattaa vahingoittaa enemmän pitkällä aikavälillä. Mitä enemmän he viivästyttävät testitapausten kirjoittamista, sitä vaikeampaa on saada kiinni kehityksen etenemisestä. Pahimmassa tapauksessa tiimisi saattaa palata takaisin vanhaan testausprosessiinsa.
Tämän voittamiseksi:
pl / sql-poikkeusten käsittely
Sinun on korostettava, että testitapausten kirjoittaminen alusta alkaen voi säästää paljon aikaa tiimillesi ja varmistaa tuotteen korkean testikattavuuden.
Sisällytä yrityskulttuuriin myös ajatus, että testitapaukset ovat yhtä arvokkaita voimavaroja kuin itse koodikanta.
4. Kehittäjät jättävät virheilmoitukset huomiotta
On yleinen ongelma, että kun isommat tiimit työskentelevät yhdessä, CI-ilmoitusten määrä tulee ylivoimaiseksi ja kehittäjät alkavat jättää ne huomiotta. Siksi on mahdollista, että he saattavat unohtaa heille tärkeät päivitykset.
Se voi johtaa vaiheeseen, jossa kooderit kehittävät suhteellisen immuniteetin rikkoutuneille koontiversioille ja virheilmoituksille. Mitä kauemmin he jättävät huomiotta asiaankuuluvat ilmoitukset, sitä kauemmin ne kehittyvät ilman palautetta väärään suuntaan. Tämä voi aiheuttaa valtavia palautuksia, rahan, resurssien ja ajan tuhlausta.
Tämän voittamiseksi:
Lähetä vain kriittisiä päivityksiä.
Lähetä ilmoitus vain vastaaville kehittäjille, jotka vastaavat sen korjaamisesta.
CT (jatkuva testaus) sisäänDevOpsin reaaliaikaiset skenaariot
Vaatimusten määrittelyoikeuden saaminen
Jos saat vaatimuksesi oikein, melkein puolet taistelusta voitetaan. Joten jos sinulla on hyvin tarkka ja tarkka käsitys vaatimuksista, voit suunnitella testisuunnitelmat paremmin ja kattaa vaatimukset hyvin.
Silti monet joukkueet käyttävät paljon aikaa ja vaivaa yksinkertaisesti vaatimusten selventämiseen. Tämä on hyvin yleinen kuoppa, ja tämän välttämiseksi joukkueet voivat käyttää mallipohjaisia testaus- ja käyttäytymisohjattuja kehitystekniikoita. Tämä auttaa suunnittelemaan testiskenaariot tarkasti ja riittävästi.
Nämä käytännöt auttavat varmasti korjaamaan ja korjaamaan aukot nopeammin. Lisäksi se antaa heille mahdollisuuden tuottaa enemmän testitapauksia automaattisesti jo sprintin alkuvaiheista lähtien.
Putkijärjestely
Jatkuvan testauksen ja jatkuva toimitus ovat läheisesti sidoksissa putkijärjestelyihin. Tämä tarkoittaa suoraan ymmärtämistä, miten se toimii, miksi se toimii, miten analysoida tuloksia ja miten ja milloin skaalata. Kaikki riippuu putkilinjasta, joten putki on integroitava automaatiopakettiin.
Mutta syy joukkueiden kävelemiseen on, että mikään yksittäinen ratkaisu ei tarjoa täydellistä työkaluketjua, jota tarvitaan CD-putkilinjan rakentamiseen.
Joukkueiden on tyypillisesti etsittävä itselleen oikeat palapelin palaset. Ei ole olemassa täydellisiä työkaluja, tyypillisesti vain rodun parhaita työkaluja, jotka tarjoavat integraatioita useiden muiden työkalujen kanssa. Ja tietysti API, joka mahdollistaa myös helpot integroinnit.
Lyhyesti sanottuna on mahdotonta toteuttaa jatkuvaa testausta ilman standardoidun ja automatisoidun putkilinjan nopeutta ja luotettavuutta.
Monimutkaisuuden lisääminen ja hallinta
Toinen tärkeä skenaario on, että jatkuva testaus muuttuu monimutkaisemmaksi siirtyessä kohti tuotantoympäristöä. Testien lukumäärä ja monimutkaisuus kasvavat kypsymiskoodin ja ympäristön monimutkaistumisen myötä.
Testit on päivitettävä joka kerta, kun päivität eri vaiheet ja automaattiset komentosarjat. Tämän seurauksena testien suorittamiseen kuluva kokonaisaika taipumus kasvaa myös kohti julkaisua.
Ratkaisu tähän on parannettu testijärjestely, joka tarjoaa oikean määrän testiä lyhyemmissä sprinttijaksoissa ja antaa joukkueille mahdollisuuden toimia luotettavasti. Ihannetapauksessa koko prosessi on automatisoitava CT: llä eri vaiheissa. Tämä tapahtuu käytäntöporttien ja manuaalisten toimenpiteiden avulla, kunnes koodi työnnetään tuotantoon.
Palautesilmukoiden luominen
Jatkuva testaus ei ole mahdollista ilman toistuvia palautesilmukoita kehitysvaiheen jokaisessa vaiheessa. Tämä on osittain syy siihen, miksi TT on vaikea toteuttaa. Et tarvitse vain automatisoituja testejä, mutta tarvitset myös testitulosten ja suorituksen näkyvyyden.
Perinteiset palautesilmukat, kuten lokityökalut, koodiprofilterit ja suorituskyvyn seurantatyökalut, eivät ole enää tehokkaita. He eivät toimi yhdessä eivätkä anna riittävästi tietoa ongelmien korjaamiseen. Reaaliaikaiset koontinäytöt, jotka tuottavat raportteja automaattisesti ja toimintakykyistä palautetta koko SDLC: n kautta, auttavat julkaisemaan ohjelmiston nopeammin tuotantoon pienempien vikojen kanssa. Reaaliaikainen pääsy koontinäyttöihin ja kaikkien tiimin jäsenten käyttö helpottaa jatkuvaa palautemekanismia.
Ympäristöjen puute
Jatkuva testaus tarkoittaa yksinkertaisesti testaamista useammin, mikä edellyttää useiden ympäristöjen lyömistä useammin. Tämä on pullonkaula, jos mainittuja ympäristöjä ei ole käytettävissä vaadittuna aikana. Jotkut ympäristöt ovat saatavilla API: n ja jotkut eri rajapintojen kautta. Jotkut näistä ympäristöistä voidaan rakentaa modernilla arkkitehtuurilla, kun taas toiset monoliittisilla vanhoilla asiakas / palvelin- tai keskusyksikköjärjestelmillä.
Mutta tässä on kysymys siitä, miten koordinoit testausta eri ympäristöomistajien kautta? On myös mahdollista, että ne eivät aina pidä ympäristöjä toiminnassa. Vastaus tähän on Virtualisointi . Virtualisoimalla ympäristö, voit testata koodia huolehtimatta liikaa alueista, jotka eivät muutu.Ympäristöjen tekeminen saataville ja saataville virtualisoinnin avulla auttaa varmasti poistamaan merkittävän pullonkaulan putkistosta.
CD (jatkuva toimitus) sisäänDevOpsin reaaliaikaiset skenaariot
Käyttöönotto kestää liian kauan
Jaetut sovellukset edellyttävät yleensä muuta kuin tiedostojen kopiointia ja liittämistä palvelimelle. Monimutkaisuudella on taipumus kasvaa, jos sinulla on palvelinten tila. Epävarmuus siitä, mitä ottaa käyttöön, missä ja miten, on melko normaali asia. Lopputulos? Pitkät odotusajat, jotta artefaktimme pääsevät reitin seuraavaan ympäristöön viivästyttämään kaikkea, testausta, aikaa elää jne.
Mitä DevOps tuo pöydälle? Kehitys- ja IT-operatiiviset ryhmät määrittelevät käyttöönottoprosessin moitteettomassa yhteistyöistunnossa. Ensinnäkin he tarkistavat, mikä toimii, ja siirtyvät sitten seuraavalle tasolle automaation avulla jatkuvan toimituksen helpottamiseksi. Tämä lyhentää huomattavasti käyttöönoton ajoitusta ja tasoittaa tietä useammalle käyttöönotolle.
Puuttuvat artefaktit, komentosarjat ja muut riippuvuudet
Me kohtaamme usein epäonnistumisia uuden ohjelmiston käyttöönoton jälkeen. Tämä johtuu usein siitä, että puuttuvia kirjastoja tai tietokannan komentosarjoja ei päivitetä. Tämä johtuu yleensä epäselvyydestä siitä, mitkä riippuvuudet otetaan käyttöön ja niiden sijainti. Kehityksen ja toiminnan välisen yhteistyön edistäminen voi auttaa ratkaisemaan tällaiset ongelmat useimmissa tapauksissa.
Automaation osalta voit määrittää riippuvuudet, jotka auttavat paljon käyttöönoton nopeuttamisessa. Kokoonpanonhallintatyökalut, kuten Nukke tai Päällikkö edistää ylimääräistä riippuvuuksien määrittelyä. Voimme määritellä riippuvuuksien lisäksi sovelluksessamme myös infrastruktuurin ja palvelimen kokoonpanotasolla. Esimerkiksi voimme luoda virtuaalikoneen testiä varten ja asentaa / konfiguroida kollikissa ennen esineiden julkaisemista.
Tehoton tuotannonvalvonta
Joskus määrität valvontatyökalut tavalla, joka tuottaa paljon epäolennaisia tietoja tuotannosta, mutta toisinaan ne eivät tuota tarpeeksi tai ei ollenkaan. Ei ole määritelmää siitä, mitä sinun tulee huolehtia ja mitkä ovat mittarit.
Sinun on sovittava siitä, mitä seurataan ja mitkä tiedot tuotetaan, ja sitten asetettava hallintalaitteet. Sovelluksen suorituskyvyn hallintatyökalut ovat suuri apu, jos organisaatiollasi on varaa tarkastella AppDynamicsia, New Reliciä ja AWS X-Rayä.
DevOps-dataskenaariot
DevOpsin tarkoituksena on poistaa uusiin ohjelmistokehitykseen liittyvät riskit: Data-analyysillä tunnistetaan nämä riskit. DevOps-prosessin jatkuvaan mittaamiseen ja parantamiseen analytiikan tulisi ulottua koko putkilinjalle. Tämä tarjoaa arvokasta tietoa johtamisesta ohjelmistokehityksen elinkaaren kaikissa vaiheissa.
1. Vähemmän aikaa tietojen analysointiin
Kaikilla tietyllä hetkellä syntyvillä tiedoilla organisaatioiden on hyväksyttävä, etteivät ne voi analysoida kaikkea. Aikaa ei yksinkertaisesti ole tarpeeksi päivässä - ja valitettavasti robotit eivät ole vielä riittävän hienostuneita tekemään kaiken meille vielä.
valinta lajitteluohjelma java
Tästä syystä on tärkeää määrittää, mitkä tietojoukot ovat merkittävimpiä. Useimmissa tapauksissa tämä tulee olemaan erilainen jokaisessa organisaatiossa. Joten määritä liiketoiminnan keskeiset tavoitteet ja tavoitteet ennen sukellusta. Tavallisesti nämä tavoitteet kiertävät asiakkaiden tarpeita - ensisijaisesti arvokkaimpia ominaisuuksia, jotka ovat tärkeimpiä loppukäyttäjille. Esimerkiksi vähittäiskauppiaan luettelon kärjessä on analysoida liikenteen vuorovaikutus sivuston kassasivun kanssa ja testata, miten se toimii taustapuolella.
Joitakin nopeita vinkkejä analysoitavien tietojen tunnistamiseksi:
Tee kaavio: Määritä keskeytysten vaikutukset yritykseesi ja kysy esimerkiksi: ”Jos X rikkoo , miten sillä on muita ominaisuuksia? '
Tarkastele historiallisia tietoja: Selvitä, missä ongelmia on syntynyt aiemmin, ja jatka testien ja analyysien tietojen analysointia varmistaaksesi, että niitä ei enää tapahdu.
2. Vaikea viestintä
Nykyään useimmat organisaatiot toimivat edelleen eri tiimien ja henkilöiden kanssa tunnistamassa omat tavoitteensa ja hyödyntämällä omia työkalujaan ja tekniikoitaan. Jokainen joukkue toimii itsenäisesti, irrotettuna putkilinjasta ja tapaa muita tiimejä vain integraatiovaiheessa.
Kun tarkastellaan laajempaa kuvaa ja tunnistetaan mikä toimii ja ei, organisaatio pyrkii löytämään yhden ratkaisun. Tämä johtuu lähinnä siitä, että kaikki eivät pysty jakamaan kokonaistietoja, mikä tekee analyysistä mahdotonta.
Tämän ongelman ratkaisemiseksi tarkistetaan viestintävirta varmistaaksesi, että kaikki tekevät yhteistyötä koko SDLC: ssä, ei vain integraatioprosessin aikana.
Varmista ensin, että DevOps-mittareissa on vahva synkronointi alusta alkaen. Jokaisen joukkueen edistymisen tulisi näkyä yhdessä hallintapaneelissa käyttämällä samoja keskeisiä suorituskykyindikaattoreita (KPI), jotta johto näkyisi koko prosessissa. Tämä tehdään, jotta he voivat kerätä kaikki tarvittavat tiedot analysoidakseen, mikä meni pieleen (tai mikä onnistui).
Alkuperäisen mittarikeskustelun lisäksi viestinnän tulisi olla jatkuvaa tiimikokousten tai digitaalisten kanavien kautta, kuten Slack.
3. Työvoiman puute
Lyhytaikaisessa henkilökunnassa tarvitsemme älykkäämpiä työkaluja, jotka hyödyntävät syvällistä oppimista kerätyn tiedon keräämiseksi ja päätösten tekemiseksi nopeasti. Loppujen lopuksi kenelläkään ei ole aikaa tarkastella jokaista testiä (ja joissakin suurissa organisaatioissa niitä voi olla noin 75 000 tiettynä päivänä). Temppu on poistaa melu ja löytää oikeat asiat, joihin keskittyä.
Tässä tekoäly ja koneoppiminen voivat auttaa. Monet markkinoilla olevat työkalut käyttävät tekoälyä ja ML: tä esimerkiksi seuraaviin asioihin:
Kehitä komentosarjoja ja testejä erilaisten tietojen siirtämiseksi ja vahvistamiseksi
Raportti laadusta aiemmin oppimien käyttäytymisten perusteella
Työskentele reaaliaikaisissa muutoksissa.
Joten tämän kanssa olemme päässeet tämän artikkelin loppuun DevOpsin reaaliaikaisissa skenaarioissa.
Nyt kun olet ymmärtänyt, mitä DevOpsin reaaliaikaiset skenaariot ovat, tutustu tähän Edureka, luotettava verkko-oppimisyritys, jolla on yli 250 000 tyytyväisen oppijan verkosto, joka levisi ympäri maailmaa. Edureka DevOps -sertifiointikoulutuskurssi auttaa oppijoita ymmärtämään DevOpsia ja saa asiantuntemusta erilaisista DevOps-prosesseista ja työkaluista, kuten Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack ja GIT SDLC: n useiden vaiheiden automatisoimiseksi.
Onko sinulla kysymys meille? Mainitse se tämän kommenttiosassaDevOpsin reaaliaikaiset skenaariot -artikkelija palaamme sinuun.