DevOps ei ole menetelmä eikä työkalu, se on kulttuuri



DevOps on käytäntö, jonka mukaan toiminta- ja kehitysinsinöörit osallistuvat yhdessä koko käyttöiän ajan suunnittelusta kehitysprosessiin tuotannon tukemiseen. Ketteryyden tuominen järjestelmään voidaan katsoa DevOps-kulttuuriksi.

Kulttuuri jätetään usein huomiotta ja ymmärretään väärin, mutta se on kuitenkin keskeinen tekijä yrityksen toiminnan kannalta. Jos emme hallitse kulttuuriamme, päädymme väärin käytäntöihin, jotka vaikuttavat viime kädessä liiketoimintatavoitteihimme.

Ymmärtää organisaation nykyinen kulttuuri

Kulttuuri kertoo meille ryhmän tai yrityksen arvoista ja normeista. Se tunnistaa tärkeän sekä sen, miten ihmiset lähestyvät toisiaan ja työskentelevät toistensa kanssa.





CULTURE = 'Kuinka asiat voidaan tehdä älykkäästi menestyksen saavuttamiseksi'

Otetaan esimerkki asiakastukitiimistä. Kyseisen tiimin kulttuurin tulee olla sellainen, että he saavuttavat 97-98% asiakastyytyväisyydestä.



Asiakkaan ilo huomioon ottaen ensinnäkin heidän on oltava kohteliaita, vaikeissakin tilanteissa heidän on oltava hyviä kuuntelijoita sekaannusten välttämiseksi, kun heidän on priorisoitava työ vaatimusten mukaan.

Pysähdytään hetkeksi ja kysytään itsellemme muutamia kysymyksiä:

  • Mikä on yritykseni kulttuuri nyt?
  • Kuinka hyvin tämä kulttuuri on sopusoinnussa liiketoimintatavoitteideni tai KRA: n kanssa?
  • Mitä ongelmia voin odottaa väärinkäytöksistä?

Kaikilla organisaatioilla 4C: llä on tärkeä rooli



Organisaation 4C

joukko luokan esineitä java

Katsotaanpa nyt ohjelmistoja kehittävän organisaation kulttuuria. Yhden ohjelmistoyksikön rakentamiseen ja ylläpitoon osallistuu monia tiimejä. Kaikilla näillä joukkueilla on erilliset tavoitteet ja erillinen kulttuuri.

Tämä prosessi alkaa, kun asiakas on vahvistanut vaatimukset.

Kehittäjät noudattavat organisaationsa määrittelemiä koodausohjeita, ja koodin luomiseen käytetään ohjelmointityökaluja, kuten kääntäjiä, tulkeja, virheenkorjaajia jne. Koodaamiseen käytetään erilaisia ​​korkean tason ohjelmointikieliä, kuten C, C ++, Pascal, Java ja PHP.

He jakavat koko paketin pieniksi kansioiksi ja kehittävät sitten pienet koodit vastaavasti.

Vaihe 1 : Nämä pienet koodiyksiköt yhdistetään sitten suureksi yksiköksi. Pienempien sirujen integroinnin yhteydessä on suoritettava projektitason testaus, joka tunnetaan nimellä integrointitestaus.

Vaihe 2 : Onnistuneen integroinnin jälkeen se otetaan käyttöön nuken järjestelmään. Tällä nuken järjestelmällä on samanlainen kokoonpano kuin asiakaskoneella tai koneella, johon tämä projekti on lopullisesti otettava käyttöön.

Vaihe 3 : Lopuksi, testattuaan kaikki nuken järjestelmän ominaisuudet projekti viedään tuotantopalvelimeen tai asiakaskoneeseen.

Vaikka tämä prosessi näyttää olevan hyvin sujuva ja helppo sanoin, teknisesti se on erittäin vaikea saavuttaa.

Katsotaanpa, mitä ongelmia voimme kohdata:

Vaihe 1 :

Asiakas etsii aina muutoksia tuotteen laadun parantamiseksi. Suurimman osan ajasta, jolloin ensimmäinen iterointi tehtiin, asiakas ehdottaa muutamia muutoksia. Kun kehittäjät saavat muutokset, he alkavat sisällyttää ne, mikä vaikuttaa integrointiin, joka johtaa rikkoutuneisiin koontiversioihin.

Vaihe 2:

Suurimman osan ajasta testaajat tai muut operaatiopojat eivät ole tietoisia uusista muutoksista. Heti kun he saavat koodin kehittäjiltä, ​​he alkavat testata niitä. Kehittäjät tekevät edelleen muutoksia taustalla.

Koska heillä ei ole tarpeeksi aikaa uusien muutosten toteuttamiseen, he lopulta kehittävät tehottomia koodeja, jotka kohtaavat muita verkko- ja tietokantakysymyksiä, mikä taas viivästyttää niiden toimitusaikaa.

Kun he vihdoin toimittavat koodit operatiiviselle ryhmälle, heillä on hyvin vähän aikaa luoda ja toteuttaa uusia testitapauksia. Joten he ohittavat monet testitapauksista, jotka ymmärtävät myöhemmin, että ne olivat erittäin tärkeitä.

Vaihe 3:

miten lopettaa ohjelma java

Vaikka käytännössä koontiversio näyttää olevan valmis aloittamaan tuotanto, mutta tulokset ovat täysin odottamattomia. Rakennus epäonnistuu ja esiintyy useita virheitä.

Sitten jokaisen virheen kohdalla heidän on seurattava, miksi se tapahtui, missä se tapahtui, mitä muutoksia on tehtävä sen poistamiseksi, muutetaanko muiden koodeja, jotta se olisi yhteensopiva aiempien koodien kanssa. Lopuksi kaikista näistä virheistä on luotava virheraportti.

Epäonnistuminen johtuu järjestelmävirheistä, jotka johtuvat tietokannan kehittäjän tietämättömyydestä koodin tehokkuudessa, testaajan tietämättömyydestä testitapauksissa jne.

Koska asiakas pitää aina määräaikaa tiukana, niiden saavuttamiseen osallistuvat työntekijät keskittyvät vain lopulliseen julkaisuun, vaikka heidän pitäisi vaarantaa yleinen laatu.

Vaikka tämä näyttää olevan ongelma työn koordinoinnissa, tämä on oikeastaan ​​käytetyn kulttuurin epäonnistuminen.

Tämä johtuu suuresta riippuvuudesta manuaalisista prosesseista. Juoksu edestakaisin samassa joukkueessa tiedon puutteen takia eri alojen pääsyn puute tai kiinnostuksen puute voi lisätä omaa taakkaa ja kipua.

On korkea aika, että meidän on oltava monipuolisia. Voi olla vaikeaa hallita kaikkia järjestelmään liittyviä prosesseja, mutta voimme olla kaikkien tunkeilija, hallita yhtä heidän joukossaan. Sitten vain me voimme automatisoida järjestelmämme tai tehdä siitä tarpeeksi älykäs palautumiseen pikemminkin kuin palautuksiin.

Nyt saatat ajatella miksi?

Se johtuu siitä, että hallitsemasi henkilö on hyvin riippuvainen muista. Joten tietääksemme riippuvuuskohdan, meidän on ymmärrettävä koko järjestelmä.

Ajatelkaamme siis prosessia kulttuurin muuttamiseksi. Ennen sitä sinulla on vastaus alla oleviin kysymyksiin?

  • Missä nykyinen kulttuurisi epäonnistuu?
  • Miksi haluat muuttaa prosessia?
  • Oletko yksilöinyt kaikki tarvittavat muutokset?
  • Oletko saanut palautetta ja sisäänostoja kaikilta asianomaisilta sidosryhmiltä?
  • Oletko uusinut prosessin kurinalaisuuden, tiedot ja mittausjärjestelmän muutokselle?

Joten nyt, kun meillä on vastaus kaikille, ajattelemme järjestelmämme vallankumousta. Kuinka tämä vallankumous tapahtuu? Se voidaan saavuttaa vain silloin, kun tapamme nykyisen. Paljon aikaa tuhlataan koodien siirtämisessä joukkueiden välillä. Meidän on saatava prosessi sinne, missä voimme tehdä jatkuvan integraation ja jatkuvan käyttöönoton.

Tämä jatkuva integrointi ja käyttöönotto tekee siitä ketterämmän. Tämän ketteryyden tuomista pidetään DevOps-kulttuurina.

DevOps on käytäntö, jossa toiminnot ja kehitysinsinöörit osallistuvat yhdessä koko palvelun elinkaareen suunnittelusta kehitysprosessiin tuotannon tukemiseen.

Toimintajärjestelmän vaihtaminen ei ole helppoa ajan myötä. Onnistunut siirtyminen on järjestelmän uudistaminen eikä uudelleenrakentaminen.

Katsotaan nyt, miten voimme saavuttaa tämän. Lähestymiseen voi olla kaksi tapaa.

1) Ylhäältä alas

2) Pohja ylös

Sukellamme syvemmälle näihin tekniikoihin ja ymmärrämme, mikä sopii parhaiten organisaatiollemme.

Ylhäältä alas -lähestymistavassa voimme mennä ylempään johtoon ja pyytää heitä tekemään muutoksia kaikissa joukkueissa. Jos johto on vakuuttunut, voimme alkaa työskennellä sen parissa.

Mutta todennäköisyys saada vastaus 'EI' on melko suuri. Tämä johtuu siitä, että järjestelmän muuttaminen voi johtaa organisaation epävakauteen.

Heidän on tutkittava organisaation rakennetta, tuloja, asiakkaan kiinnostustasoa jne. Mutta tärkein tekijä, joka vetää heitä takaisin vanhasta järjestelmästä, on se, että he eivät näe iso kuva siitä, mitä voidaan saavuttaa ja kuinka sujuvasti se voidaan saavuttaa uudemmalla.

Tässä tapauksessa voimme etsiä toista lähestymistapaa saadaksemme tämän suuren kuvan.

Alhaalta ylöspäin suuntautuva lähestymistapa vaatii vapaaehtoistyötä. Täällä meidän on otettava pieni joukkue ja pieni tehtävä ja suoritettava se DevOps-mallissa.

Tämän mallin teknistä puolta tarkasteltaessa meillä on useita hienostuneita työkaluja, jotka tekevät työstä tehokkaampaa ja nopeampaa. Työkalut eivät kuitenkaan yksin riitä luomaan yhteistyöympäristöä, jota kutsutaan nimellä DevOps.

Tällaisen ympäristön luominen vaatii ajattelua laatikosta esim. arvioida ja mukauttaa ihmisten ajattelua tiimeistään, yrityksestä ja asiakkaista.

Uuden työkalusarjan kokoaminen on yksinkertaisempaa kuin organisaatiokulttuurin muuttaminen. Edistämällä antisosiaalisia pääkehittäjiä, sallimalla tehottomien koodien integrointi, ottamalla käyttöön koodeja, joita ei ole testattu asianmukaisesti, asettamalla syytöksiä toistensa päähän ja pitämällä toimintaryhmää tyhmänä, ne eivät ole parhaita käytäntöjä, joita seuraamme liiketoiminnan mahdollistamiseksi ja luoda arvoa asiakkaillemme.

java miten lopettaa ohjelma

Työkalut eivätkä niitä käyttävät ihmiset tekevät prosessista monimutkaisen. Sanominen abstraktilla tasolla mieluummin kuin ideoiden ja käyttäytymismallien kerääminen, avoimuus heille vie meidät valoisalle polulle.

Aloitetaan 6-jäsenisestä tiimistä ja 3-pisteisestä tarinasta. Ensinnäkin meidän on hajottava tiimi, jota kutsumme kehittäjiksi, operaatioiksi, testaajiksi jne. Pidämme kaikkia heitä yhtenä, sanotaan 'DevOps'. Kun saamme vaatimukset, meidän on analysoitava riskialueet. Pitäen mielessä syvemmät merialueet ja helvetti .. Alamme purjehtia.

Nyt sinun täytyy ajatella 'mikä on näiden jatkuvan integroinnin ja jatkuvan käyttöönoton x-tekijä, joka vähentää epäonnistumisen todennäköisyyttä'.

Parannetun vision ja prosessin avulla voimme lähestyä johtoa antamalla selkeän kuvan tuloksista, kuten kuinka sujuva prosessi oli, kuinka epäonnistumisriski pieneni, miten tehtävä suoritettiin ennen aikajanaa jne.

Nyt voimme selkeästi visualisoida, kuinka koko prosessi optimoitiin teknisellä ja kulttuurillisella tasolla katsomalla jokaisen iteraation jälkeen.

Edureka on erityisesti kuratoinut Se auttaa sinua hallitsemaan konsepteja mm. Puppet, Jenkins, Ansible, SaltStack, Chef.

Onko sinulla kysymys meille? Mainitse ne kommenttiosassa ja palaamme sinuun.

Aiheeseen liittyvät julkaisut: