Minne tällä tiedolla mennä, mitä tehdä projektissa ja kuinka paljon ansaita, mitä sanoa ja kysyä haastattelussa - sanoo Alexander Titov, Express 42:n toimitusjohtaja ja kirjoittaja .
Hei! Vaikka termi DevOps on ollut olemassa vuodesta 2009 lähtien, venäläisyhteisössä ei vieläkään ole yksimielisyyttä. Olet luultavasti huomannut, että jotkut pitävät DevOpsia erikoisuutena, toisten mielestä se filosofia ja toisten mielestä termi tekniikoiden joukko. Olen esiintynyt jo monta kertaa tämän suunnan kehityksestä, joten en mene yksityiskohtiin tässä artikkelissa. Haluan vain sanoa, että Express 42:ssa sisällytämme siihen seuraavat:
DevOps on erityinen metodologia, digitaalisen tuotteen luomisen kulttuuri, jossa kaikki tiimin asiantuntijat osallistuvat tuotantoon.
Klassisessa yrityskehityksessä kaikki menee peräkkäin: ohjelmointi, testaus ja vasta sitten käyttö, ja tämän prosessin nopeus ideasta tuotantoon on 3 kuukautta. Tämä on digitaalisten tuotteiden globaali ongelma, koska asiakkailta on mahdotonta saada nopeasti palautetta.
DevOpsissa työkalut ja lähestymistavat on suunniteltu varmistamaan, että kehitys-, testaus- ja käyttöprosessit toimivat samanaikaisesti.
Mitä tästä lähestymistavasta seuraa?
- Et voi palkata "insinööriä", joka tulee ja ratkaisee kaikki tuotannon ongelmat. Koko joukkueen tulee soveltaa tekniikkaa.
- DevOps EI OLE seuraava järjestelmänvalvojan muoto, johon päivitetään. "DevOps-insinööri" kuulostaa suunnilleen samalta kuin "ketteri kehittäjä".
- Jos tiimi käyttää Kubernetesia, Ansiblea, Prometheusta, Mesosphereä ja Dockeria, tämä ei tarkoita, että siellä olisi otettu käyttöön DevOps-käytäntöjä.
Elämä DevOpsin jälkeen ei ole koskaan entisensä
DevOps-lähestymistapa on ennen kaikkea erilainen ajattelutapa, käsitys kehityksestä kokonaisuutena ja omasta paikasta prosessissa. Jaoimme verkkokurssimme kahteen lohkoon:
1. Itsemääräämisoikeus
Ensin tarkastelemme yksityiskohtaisesti DevOps-lähestymistavan olemusta, ja opiskelijat löytävät tiimissä uusia rooleja, näkevät kumpi vastaa enemmän ja päättävät itse, mihin suuntaan he haluavat kehittyä.
2. Työkalut ja käytännöt
Opiskelija hallitsee tiettyjä teknologioita DevOps-menetelmän näkökulmasta.
DevOps-työkaluja voidaan käyttää sekä DevOps-lähestymistavassa että klassisessa kehityksessä. Ilmeisin esimerkki olisi Ansible-kokoonpanonhallintatyökalun käyttö. Se on luotu ja suunniteltu toteuttamaan DevOps-käytäntöä "Infrastructure as Code", mikä tarkoittaa, että järjestelmän eri tilat kuvataan käyttöjärjestelmän asetuksista sovellusohjelmistoihin. Kuvaus on jaettu tasoihin, ja sen avulla voit hallita monimutkaista, jatkuvasti muuttuvaa kokoonpanoa. Mutta insinöörit käyttävät usein Ansiblea tapana suorittaa bash-skriptejä useissa koneissa. Tämä ei ole huono eikä hyvä, mutta sinun on ymmärrettävä, että Ansiblen läsnäolo ei takaa DevOpsin läsnäoloa yrityksessä.
Olemme prosessissa Tulet uppoutumaan kuuluisan Redditin kaltaisen sovelluksen kehitysprosessiin, alkaen sen monoliittisesta versiosta ja siirtymällä askel askeleelta mikropalveluihin. Askel askeleelta hallitsemme uusia työkaluja: Git, Ansible, Gitlab ja viimeistelemme Kubernetesin ja Prometheuksen.
Käytännöissä noudatamme DevOps Handbookissa kuvatun kolmen polun taktiikkaa - jatkuvatoimituskäytännöt, palautekäytännöt ja koko kurssin ydin on jatkuvan oppimisen harjoittelu järjestelmän mukana.
Mitä tämä tieto antaa kullekin asiantuntijalle?
Järjestelmänvalvojille
Käytäntöjen avulla voit siirtyä hallinnosta jatkuvan toimitusputken ja infrastruktuurialustan luomiseen ohjelmistotoimituksiin. Asia on siinä, että hän luo tuotteen – infrastruktuurialustan kehittäjille, joka auttaa heitä siirtämään muutokset nopeasti tuotantoon.
Aiemmin järjestelmänvalvojat olivat viimeinen linnake, jonka jälkeen kaikki menee tuotantoon. Ja pohjimmiltaan he harjoittivat jatkuvaa palontorjuntaa - jonka valossa on melko vaikeaa syventää liiketoiminnan tarpeita, ajatella tuotetta ja hyötyjä käyttäjälle.
DevOps-menetelmän ansiosta ajattelu muuttuu. Järjestelmänvalvoja ymmärtää kuinka konfiguraatio muutetaan koodiksi, mitä käytäntöjä tähän on olemassa.
Tämä on tärkeää, koska yritykset ymmärtävät yhä enemmän, että kaikkea ei tarvitse vain automatisoida, ts. mitä vanhan koulun järjestelmänvalvojat olivat pääosin tottuneet tekemään, jotka plus tämä kommunikoivat vähän eivätkä tiedottaneet tiimille kaikista tehdyistä muutoksista. Nyt tiimit etsivät niitä, joista tulee sisäisen infrastruktuurituotteen valmistaja ja jotka auttavat yhdistämään erotetut prosessit yhdeksi.
Kehittäjät
Kehittäjä lakkaa ajattelemasta vain algoritmeissa. Hän hankkii taidot työskennellä infrastruktuurin parissa, taidot maiseman arkkitehtoniseen tietoisuuteen. Tällainen kehittäjä ymmärtää, kuinka sovellus toimii, kuinka se kulkee jatkuvan toimitusputken läpi, kuinka sitä seurataan, kuinka se rekisteröidään niin, että se hyödyttää asiakasta. Tämän seurauksena kaiken tämän tiedon avulla voit kirjoittaa asiaankuuluvaa koodia.
Testaajille
Testaus on jo pitkään siirtynyt automaattiseen tilaan, me kaikki sanomme, että monia testejä ei pidä tehdä, vaan kirjoittaa :) Testauksesta tulee osa tuotteesi koko toimitusketjua. Testaajan ei tarvitse vain opetella kirjoittamaan koodia, vaan myös ymmärtämään, kuinka se integroidaan jatkuvaan toimitusjärjestelmään, kuinka saada palautetta koodista kaikissa toimituksen vaiheissa ja kuinka jatkuvasti parantaa testausta virheiden havaitsemiseksi. mahdollisimman aikaisin.
Joten käy ilmi, että kaikki kolme vaihetta tapahtuvat samanaikaisesti. Se voi näyttää esimerkiksi tältä:
Kehittäjä kirjoittaa koodin, kirjoittaa sille välittömästi testit ja kuvailee ajettavalle koodille telakointisäiliön. Siinä kuvataan välittömästi myös valvonta, joka seuraa tämän palvelun toimintaa tuotannossa, ja sitoutuu tähän kaikkeen.
Kun jatkuva integraatio alkaa, prosessit toimivat samanaikaisesti. Palvelu käynnistyy ja konfiguroidaan. Samaan aikaan telakointikontti käynnistyy ja tarkistetaan, että se on käynnissä. Samalla kaikki tiedot siirtyvät lokijärjestelmään. Ja niin edelleen jokaisessa kehitysvaiheessa – se osoittautuu todelliseksi järjestelmänvalvojien, kehittäjien ja testaajien ryhmätyöksi.
Opiskelin DevOpsia, mitä seuraavaksi?
Kuten tiedät, kentällä oleva ei ole soturi. Jos yrityksesi ei käytä tätä menetelmää, hankitut taidot jäävät käyttämättä. Ja kun olet tutustunut DevOps-lähestymistapoihin, et todennäköisesti halua olla yrityskehityksen hammasratas. Voi olla yksi poikkeus: olet tiimin järjestelmänvalvoja ja voit rakentaa kaikki prosessit uudelleen uudella tavalla. Tähän kannattaa lisätä, että tätä lähestymistapaa käyttäviä yrityksiä on paljon, eivätkä rajoitukset vaikuta niihin ja he etsivät asiantuntijoita. Koska DevOps on verkkotuotteiden luomista.
Ja nyt hyvistä asioista: DevOps-käytäntöjen ja -työkalujen hallinta on noin +30 % arvostasi työmarkkinoilla. Palkat alkavat 140 tuhannesta ruplasta, mutta ne määräytyvät luonnollisesti pääerikoisuutesi ja toiminnallisuutesi mukaan.
Voit katsoa "infrastruktuurikeskeisiksi" merkittyjä avoimia työpaikkoja, joissa on testiautomaatiota, mikropalvelusovellusten kehitystä pilviteknologioiden avulla, avoimia infrastruktuuriinsinöörien työpaikkoja ja kaikenlaisia viittauksia DevOpsiin. Muista vain, että jokainen yritys tarkoittaa jotain erilaista tällä määritelmällä - lue kuvaus huolellisesti.
Kurssimme käynnistyessä sain oivalluksen - monet kurssin jälkeen joutuvat DevOps-insinöörin ansaan. He löytävät avoimen työpaikan yllä mainitulla nimikkeellä, saavat hyvän tarjouksen ja tulevat sitten töihin ja ymmärtävät, että heidän on ylläpidettävä kolmisivuista bash-käsikirjoitusta Jenkinsissä. Missä ovat Kubernetes, ChatOps, kanarian julkaisut ja kaikki tämä? Mutta ei mitään, koska yritys ei tarvitse DevOpsia menetelmänä, vaan käyttää yksittäisiä innovaatioita.
Tämä on syy selvittää yritykseltä intensiivisesti kuinka ohjelmistotoimitusprosessi toimii, teknologiapino ja mitä vastuita aiot suorittaa.
Jos työnantaja vastaa kysymyksiisi abstraktisti, kuin kirjasta, ilman yksityiskohtia, niin todennäköisesti yrityksessä ei ole vielä DevOps-prosessia, mutta tämä ei ole syy kieltäytyä, tutkia yritystä ja sen tuotteita, onko verkossa yrityksen itsensä kehittämät palvelut, mobiilisovellukset, tuoteideat.
Jos kyllä, niin selvitä, onko sinun työskenneltävä suoraan näiden järjestelmien kanssa vai onko mahdollista siirtyä vaakasuoraan näiden palveluiden ryhmiin samalla kun osoitat hyviä tuloksia DevOps-käytännöissä. Jos kyllä, niin kannattaa mennä ja olla aktiivinen ja hyödyllinen, ja jos suoritat kurssimme, jälkimmäinen on taattu.
On tärkeää huomata, että Devops-harjoittajat saavat todellista arvoa vain, kun he ovat kokeneet kehitys-/hallinta-/testauskokemuksella. Vain silloin tieto ei ole abstraktia, vaan rikastuttaa asiantuntijaa (kaikessa mielessä). Siksi ajatus "opetella DevOps tyhjästä" on suunnilleen sama kuin oppia "käyttöön objektiiveja tyhjästä", jos et ole koskaan pitänyt kameraa käsissäsi tai ohjannut kuvausta. Auttaaksemme sinua päättämään, sopiiko kurssi sinulle, olemme tehneet pääsykokeen, joka tarkistaa riittävän tietotasosi.
Mielestäni yksi temppu - että jokainen opiskelija päättää harjoittelun aikana itse, mihin suuntaan hän haluaa kehittyä. Näemme usein siirtymiä, kun kehittäjästä tulee infrastruktuuriinsinööri ja järjestelmänvalvoja tajuaa olevansa kiinnostunut koodin kirjoittamisesta - sitten hän opiskelee kieltä ja täydentää sitä hankkimillaan DevOps-taidoilla. Siksi toivotamme erityisen tervetulleeksi ne, jotka kokevat uransa juuttuneen tienhaaraan. Kurssi alkaa 28., mutta mukaan voi liittyä 2 viikkoa tuntien alkamisen jälkeen. Voit katsoa ohjelman ja suorittaa testin . Nähdään OTUS:ssa!
Lähde: will.com