DevOps-siirtymän ymmärtäminen
Johan Abildskov
Johan has been a Continuous Delivery Consultant with Eficode Praqma since 2015. After achieving his BSc in Computing Science he spent his time teaching, coding, hacking and studying. He is an avid gamer and participates in tournaments whenever he has the time. He also plays the bass.
Kaikki haluavat DevOpsin! Uusien asioiden käyttöönotto organisaatiossa on silti aina haastavaa.
Se on seikkailu, ja matkallasi on sekalainen joukko kumppaneita. Tarkastelemme näitä hahmoja Inside Out -elokuvan porukan avulla ja sitä, miten kenestä tahansa voi tulla loistava matkakumppani!
DevOps-kiertotie
Ennen kuin pääsemme alkuun, meidän täytyy luultavasti puhua hetki tästä DevOps-asiasta. DevOpsin määritelmästä kiistellään paljon. Tässä blogikirjoituksessa DevOpsilla tarkoitetaan käytäntöjen kokonaisuutta, joka painottaa automaatiota, sovellusten kokonaisvaltaista tarkastelua sekä ohjelmistokehityksen ja käyttöönoton nopeutta. Kyse on siis ohjelmistojen kehittämisestä, niiden toimittamisesta asiakkaille ja siitä huolehtimisesta, että ne toimivat myös toimituksen jälkeen.
Uskomme, että DevOps ja Continuous Delivery ovat alalle yhtä merkittäviä kuin Agile on ollut. Kehittäjät katsovat hämmentyneen alistuneina organisaatioita, jotka eivät hyödynnä Continuous Deliveryä ja DevOpsia. Tarkastellaan siis hahmoja, joita saatat kohdata matkallasi kohti modernia ohjelmistokehitystä.
Tervetuloa päämajaan
Inside Out -elokuvassa olemme Riley-nimisen tytön pään sisällä. Perustunteilla – vihalla, inhollla, pelolla, ilolla ja surulla – on yhteinen ohjauspaneeli, ja näiden eri näkökulmien yhdistelmä muodostaa Rileyn persoonallisuuden ja käyttäytymisen. Vaikka tunteet ovat ilmeinen yksinkertaistus, ne ovat auttaneet monia ymmärtämään paremmin tunteiden toimintaa. Kokeillaan siis samaa yksinkertaistusta teknologiaorganisaation DevOps-siirtymään.
Ilo
Ilon maailmassa kaikki on mahtavaa. Ilo on edelläkävijä, aina kokeilemassa uutta, ja yleensä parempi aloittamaan asioita kuin viemään niitä loppuun. Ilon kaltaisia ihmisiä tarvitaan – tarvitsemme kaikki on mahtavaa -asennetta. On kuitenkin muistettava, ettei erilainen ole itsessään hyvä.
Meidän on arvioitava tekemiämme valintoja jatkuvasti emmekä saa vain juosta kohti hohtavaa päämäärää. Jokaisessa muutosprosessissa on tärkeää tiedostaa jatkuvasti, miksi teemme sitä mitä teemme ja miten se tukee kokonaispäämäärää. Ratkaisemme tiettyjä ongelmia – emme vain haali kassillista uusia työkaluja tekemisen vuoksi.
Ilon piirteitä omaavat ihmiset ovat usein teknologia-advokaatteja. Heihin tekee suuren vaikutuksen se, että työkalu toimii tai ylipäätään on olemassa, mutta he eivät välttämättä kiinnitä huomiota sen kypsyyteen tai käytettävyyteen – tai niiden puutteeseen. Termin Technology Apologist loi Alan Cooper kirjassaan The inmates are running the asylum.
Iloa voi olla vaikea pitää ruodussa ja toimimassa sovittujen prosessien mukaisesti. Iloa voi käyttää tulevien ongelmien varhaisena varoitusmerkkinä. Varmista, että asioiden tekeminen oikein on niin helppoa, ettei Ilo voi olla luomatta Jira-tikettiä juuri keksimästään parannuksesta.
Ilosi suosikkisitaatit:
”Näin tehdään Facebookilla”
”Löysin tämän uuden työkalun”
”Luin HackerNewsistä …”
”Ai niin, eihän se vielä ihan toimi, mutta […]”
Ilon suosikkityökalut:
Jokin, jonka hän on itse kääntänyt jostain repositoriosta löytyvästä koodista, joka on kirjoitettu trendikkäällä kielellä, kuten Rustilla tai Golla.
Tai vaihtoehtoisesti Vim.
Jokin, jonka hän on itse kääntänyt jostain repositoriosta löytyvästä koodista, joka on kirjoitettu trendikkäällä kielellä, kuten Rustilla tai Golla.
Tai vaihtoehtoisesti Vim.
Viha
Viha saa paskan hoidettua! Voit olla varma, että jos jokin on rikki, kuulet siitä Vihalta. Jos Vihan kollegat eivät aivan noudata koodaustyyliä tai tuhlaavat aikaa kokouksissa, se ei jää mainitsematta. Viha on erittäin tuottelias, mutta Vihan kanssa työskentely voi olla kuoppaista. Tuottavuus yleensä laskee, kun vihainen kehittäjä seisoo työpöytäsi ääressä säännöllisin väliajoin.
Yksi tapa toimia Vihan kanssa on varmistaa, että olette samalla kartalla ja ettei Vihalla ole epärealistisia odotuksia työnsä kohteena olevien asioiden kypsyydestä. On myös erittäin tärkeää, ettei Viha ohjaa kaikkia päätöksiänne. Muuten säntäilette kuin tulikärpäset sammuttamassa päivän du jour -paloa.
Muista kuitenkin, ettei Viha synny tyhjästä. Selvitä perimmäinen syy ja puutu siihen. Selvitä, mikä Vihalle on tärkeää, niin siitä tulee vahva liittolainen. Viha saa paskat tehtyä!
Vihahahmosi lempisitaatit:
”Putki on rikki”
”Kuka rikkoi buildini?”
”En odota IT:tä enää, ostan oman palvelimen”
Vihan lempityökalut:
Print Screen -näppäin
Outlook
Kävely työpöytäsi luo
Inho
Inholla on erittäin tärkeä tehtävä: se estää meitä myrkyttymästä. On terveellistä suhtautua uusiin työkaluihin tai toimintatapoihin tietyllä skeptisyydellä. Koska monet muutoksen edistäjät kallistuvat Iloon, Inho tuntuu meistä kovin taantumukselliselta. He epäröivät liikaa, jotta voisimme tehdä heidän kanssaan mielekästä yhteistyötä. Inho on kuitenkin monella tapaa onnistumisen mittari. Muista, että se, mikä nyt on vakiintunut käytäntö, oli joskus uutta ja inhottavaa.
Ennen kuin saamme Inhon vakuuttuneeksi, siirtymä DevOpsiin ei etene herkulliseen suuntaan. Ja koska DevOps on kuin päälle ripoteltava mauste, sen pitäisi olla herkullista. Tavoittelemamme tilanteen pitäisi olla nykytilaa houkuttelevampi.
Meidän on selvitettävä, mistä Inhon skeptisyys kumpuaa, ja poistettava myrkylliset osat. Tai keitettävä niitä niin kauan, etteivät ne ole enää tunnistettavissa. Tee Inholle pieniä parannuksia. Luo Git-alias tai pieni skripti, joka vähentää kipupisteitä.
Ikävä sanoa, mutta tässä vaiheessa saatat päätyä ottamaan kuvakaappauksia ja liittämään ne Word-asiakirjaan tai PowerPointiin.
Inhohahmosi lempisitaatit:
”Tämä näyttää aivan 90-luvun työkalulta”
”Tämä uusi kokoonpano näyttää todella monimutkaiselta”
”Älä kuvittele, että se toimii täällä vain siksi, että se toimii muualla”
”En ole varma, tuoko Gitin oppiminen yritykselle arvoa. Se on kaltaisillesi ihmisille”
Inhon lempityökalut:
IT-osaston hyväksymä IDE
Sharepoint
Pelko
Pelko on tärkeää. Pelko estää meitä loukkaantumasta. Kokemuksemme mukaan Pelko tarkastelee yleensä sitä, mikä on lyhyellä aikavälillä turvallisin reitti. Monille yrityksille turvallisinta voi olla jatkaa työskentelyä SVN:llä. Jatkaa työskentelyä kuten yleensäkin. Se kuitenkin vahingoittaa liiketoimintaa pidemmällä aikavälillä. Pelko näkee asiat Opsin näkökulmasta. Meillä on jotain, joka on pidettävä toiminnassa. Se on kaikkein tärkeintä kaikessa, mitä teemme, sillä miten muuten voisimme tuottaa arvoa asiakkaillemme? Pelko arvostaa vakautta yli kaiken.
Pelon kanssa toimiessa on tärkeää olla tekemättä mitään odottamatonta. Varmista, että sinulla on selkeä ja läpinäkyvä tiekartta aikatauluineen. Ole rehellinen, jos tiedät, että lähiaikoina tiellä on töyssyjä. Näin Pelko voi valmistautua niihin.
Ota Fear mukaan muutosprosessiin, jos mahdollista. Kun Fear on äärimmäisen ärsyttävä pilkunviilaaja, muista, että kaiken sen korjaaminen, minkä Fear huomaa ja nostaa esiin, on paljon halvempaa kuin tuotantoon päätyneiden ongelmien korjaaminen.
Suosikkisitaatteja Fear-hahmoltasi:
”En usko, että se toimii”
”Se toimii nyt, miksi sitä pitäisi muuttaa?”
”En ole varma, onko Open Source -työkalun valitseminen niin hyvä idea”
”Mistä tiedämme, että […] ?”
Fearin suosikkityökalu:
Excel
Visual Studio 2010
Neljätoistasivuinen Word-dokumentti, joka kuvaa asennusprosessin
Sadness
Sadness tuo Joylle kontekstin ja saa meidät pohtimaan asioita. Vasta kun hyväksymme tämän ja muodostamme tasapainoisen kokonaisuuden, voimme olla menestyvä DevOps-organisaatio.
Sadness on välttämätön vastapaino teknologiaa puolustelevalla Joylle. Hän varmistaa, ettemme unohda, miksi edellinen siirtymä epäonnistui. Joylle hän voi tuntua kurjalta vastustajalta. Se ei kuitenkaan ole Sadnessin tarkoitus.
Kuten Sadness sanoo: ”Itkeminen auttaa minua hidastamaan ja murehtimaan elämän ongelmien painoa”. Juuri tältä se tuntuu. Mutta ellemme murehdi hieman, ellemme käy retrospektiivejämme rehellisesti läpi ja muista sekä kipukohtia että onnistumisia, miten voimme kehittyä? Miten voimme onnistua? Sadness antaa meille kaikki tärkeät opit, joita tarvitsemme onnistuaksemme paremmin seuraavalla kerralla.
Olen pohjimmiltani Joy. Aloitan asioita, häiriinnyn helposti ja aloitan uusia asioita. Joskus unohdan, että myös todellisuus tarvitsee huomiota ja huolenpitoa. Minun on oltava hyvin tarkkana, etten yritä vain laittaa Sadnessia liidulla piirrettyyn ympyrään ja sanoa: ”älä häiritse edistystäni”.
Ärsyynnyn, kun olen (taas) saanut tämän mahtavan idean ja esitän sen henkilölle, joka osoittautuu faktapohjaiseksi, realistiseksi ja järkeväksi tyypiksi. Se auttaa minua selvittämään, mitkä ideat ovat tärkeitä ja mitkä olisi ehkä parasta jättää vain ideoiksi.
Kunnioita siis Sadnessia ja huomioi hänet – häneltä löytyy paljon totuutta.
Suosikkisitaatteja Sadness-hahmoltasi:
”Edellisessä siirtymässä unohdimme ..”
”Muista, että kaikkien täytyy sitoutua mukaan”
”Viimeksi työkalua vaihtaessamme siitä syntyi valtava vaiva, koska ….”
”Ongelma on yhä olemassa uuden työkalun kanssa, se on vain prosessin eri kohdassa”
Sadnessin suosikkityökalu:
Muisto kaikesta aiemmin kokeillusta. Yrityksen perustamisesta tähän päivään kertyneiden siirtymien aiheuttamien kipukohtien kokonaisuus.
Kahvimuki jo kauan sitten poistuneelta työkalutoimittajalta
Bing Bong
Bing Bong on Rileyn mielikuvitusystävä. Kun hän ei enää ole tärkeä, hän uhraa itsensä Rileyn mielenterveyden vuoksi.
Voimme siis nähdä hänet esimerkkinä koodikannasta tai työkaluketjusta, joka on ollut. Se oli tärkeä ja oli aikanaan organisaation toimintatavan kriittisin osa. Päätöksemme kannattaa perustaa niihin oppeihin, jotka saimme silloin, kun Bing Bong hallitsi katujamme. Häntä ei kuitenkaan pidä yrittää säilyttää keinotekoisesti eikä ylläpitää rajoituksia, jotka juontuvat tavasta, jolla ennen työskentelimme.
Kun tunnistamme, että vuosien saatossa vaivalla kokoon kyhäämämme työkaluketju mahdollisti pääsyn tähän pisteeseen, voimme hyvällä omallatunnolla sanoa sille hyvästit ja siirtyä DevOpsiin. Tämä oivallus on vaikea, etenkin yrityksissä, joiden koodikantojen ensimmäiset rivit kirjoitettiin jo ennen kuin Uberin tai Teslan kaltaisia yrityksiä oli edes perustettu.
Meidän on tunnustettava kaikki ne päätökset, jotka olivat aikanaan oikeita ja johtivat nykyiseen sotkuun. On myös tunnustettava, että muutoksella voimme päästä paljon pidemmälle.
Kohti DevOpsia
Jos olet matkalla kohti Continuous Deliveryä ja DevOpsia ja kaipaat sparrausta tai yrität vasta selvittää, mistä aloittaa, ota yhteyttä. Meillä on runsaasti kokemusta arvokkaana matkakumppanina toimimisesta näillä matkoilla.
Jos tunnistat itsesi tai jonkun kollegasi yhdeksi näistä hahmoista, kerro meille suosikkisitaattisi heiltä.
Toivotamme sinulle onnea matkaan ja hyvää mielenterveyttä.
Kaikki tämän blogikirjoituksen kuvat ovat elokuvasta Inside Out. Tekijänoikeus: ©2015 Disney/Pixar.
- DevOps
Subscribe to our newsletter
Related blogs