Frank Wickström, Andersin CTO ja yksi DevOps-tiimimme velhoista, kirjoitti blogin uudesta DevOps-alustastamme ja sen ympärillä olevista palveluista. DevOps sopii kuin nenä päähän meidän Digital sustainability -missiomme kanssa, koska DevOps-toimintamallin tarkoituksena on nopeuttaa toimitusaikaa, minimoida manuaalinen työ ja maksimoida kustannustehokkuus. Tämä on Frankin & DevOpsin tarina.
Frank Wickström, Andersin CTO ja yksi DevOps-tiimimme velhoista, kirjoitti blogin uudesta DevOps-alustastamme ja sen ympärillä olevista palveluista. DevOps sopii kuin nenä päähän meidän Digital sustainability -missiomme kanssa, koska DevOps-toimintamallin tarkoituksena on nopeuttaa toimitusaikaa, minimoida manuaalinen työ ja maksimoida kustannustehokkuus. Tämä on Frankin & DevOpsin tarina.
Frankin tarina
Kun aloitin IT-urani, yksi ensimmäisistä kiinnostavista asioista minulle oli automatisointi – miten automatisoida tylsiä ja toistuvia työtehtäviä. Vieläkin usein hämmästyttää, että ihmiset ovat tottuneet tekemään samoja asioita uudestaan ja uudestaan, kun ratkaisu tehtävien automatisointiin olisi olemassa vain muutaman napsautuksen päässä. Automatisointi ylittää jo IT-toimialan rajat ja näyttää siltä, että monet alat (kuten valmistava teollisuus) ovat jo selvittäneet suuren osan näistä asioista.
Kuitenkin, kun ohjelmistoyritykset tuottavat koodia, ihmiset stressaantuvat ja pelkäävät asioiden menevän pieleen. Kehittäjä kirjautuu palvelimelle, kopioi koodinsa ja suorittaa ”taikaskriptin”, jonka on luonut työntekijä ei enää edes työskentele yrityksessä. Sitten rukoillaan ohjelmointijumalilta, että asiat menisivät hyvin. Vielä parempi, kun koko prosessin suorittaa henkilö, jolla ei ole aavistustakaan, mitä koodi edes tekee tai mistä projektista on kyse.
Olen nähnyt omakohtaisesti tämän tapahtuvan ja kuullut useita tarinoita siitä, kuinka koko järjestelmä on kaatunut tuntikausiksi väärien konfiguraatioiden ja korruptoituneiden tietokantojen vuoksi, minkä takia ”the” kaveri oli kutsuttava korjaamaan ongelma. Olisin erittäin rikas, jos olisin saanut pennin joka kerta kun olen kuullut vuosien varrella: ”Aion päivittää palvelimeni perjantaina”. Kaikkien yritysten kanssa, joiden kanssa olen puhunut tai työskennellyt, koodin saattaminen tuotantoon ei ole ollut läpihuutojuttu.
Muutama vuosi valmistumiseni jälkeen sain mahdollisuuden olla vastuussa projektista. Se oli tilaisuuteni luoda automaattinen käyttöönottoratkaisu ja ratkaista kaikki ne kauhutarinat, joista olin jo kuullut. Muutaman päivän selvitystyön jälkeen sukellettuani automaation työkalujen, kuten Ansible, maailmaan, sain aikaan mestariteokseni. Automaattinen koodinpätkä blue-green -käyttöönottoihin.
Olin aika tyytyväinen ratkaisuuni ja suurimman osan ajasta asiat toimivat loistavasti. Mutta sitten alkoi tulla virheilmoituksia, tietokantojen migraatioita, varmuuskopioiden palauttamista, ongelmia skaalauksessa, palvelinvirheitä, SSL-varmennuksia. Oli myös vaikeuksia saada muut ymmärtämään kaunista luomustani, mutta siihen mennessä olin jo koukussa; näiden haasteiden ratkaiseminen oli nyt jotain, mitä halusin tehdä ja pidin hauskana. Halusin auttaa muita kehittäjiä, jotta heidän ei tarvitsisi keksiä pyörää uudelleen.

Men (in black) = DevOps tiimin Paul and Frank.
Kuinka rakentaa DevOps-ratkaisu
Nyt muutama vuosi myöhemmin, meillä on työkaluja ja ratkaisuja, jotka olivat vielä lapsenkengissä, kun kirjoitin ensimmäiset skriptin pätkäni. Meillä on kontteja ja orkestraatiota, esim. Docker ja Kubernetes. Nämä yleensä ratkaisevat skaalauksen ja yksinkertaisten sovellusten käyttöönoton muutamalla komennolla tai hiiren napsautuksella. Fantastista settiä. Asioiden siirtäminen tuotantoon ei silti ole niin helppoa kuin voisi tai pitäisi olla.
Halusimme Andersin kanssa tarttua tähän ongelmaan. Perehdyimme asiaan ja löysimme monia valmiita työkaluja, jotka helpottavat sovellusten käyttöönottoa, kuten jatkuvan käyttöönoton työkaluja ja ”auto DevOps” -järjestelmiä. Monet näistä työkaluista ratkaisevat havaittuja ongelmia, mutta ne olivat joko liian monimutkaisia, joustamattomia tai toimittajasidonnaisia. Teimme siis mitä mikä tahansa hullu tiimi tekisi; eli rakensimme oman ja erilaisen työkalusarjan.
Palvelun tai uuden CI/CD SaaS -tuotteen luomisen sijaan loimme kirjaston ja työkalut, jotka olivat riittävän joustavia toimimaan jo olemassa olevissa CI/CD-työkaluissa, kuten GitLab CI/CD, CircleCI ja GitHub Actions. Ainoat tekemämme edellytykset ovat Dockerin käyttö ja Kubernetes, jossa sovellus lopulta ajetaan.
Kólga — avoin työkalu kaikille
Mikä alkoi oppimistyökaluna, muuttui nopeasti työkaluksi, jolla pystyimme hoitamaan sisäiset testijulkaisut. Siitä jalostui lopulta tuote mm. Helsingin kaupungin ja Visman käyttöön. Koska DevOps-työkalumme sattuikin olemaan todella hieno innovaatio tuotannon kehittämiseen, miksi emme siis jakaisi tätä iloa? Voit tutusta siihen täällä: https://github.com/andersinno/kolga
Työkalu yhdessä DevOps-toimintamallin kanssa yhdistää sekä kehittäjien että operatiivisen puolen ponnistelut. DevOps on johtanut meillä vielä vahvemmin yhteiseen tiimipelaamiseen, joka pyrkii toimittamaan ohjelmistoja parhaalla mahdollisella tavalla ja pienimmällä vaivalla.
Oletko kiinnostunut ottamaan käyttöön ohjelmistosi potentiaalin ja pääsemään tavoitteisiisi? Haluatko saada asiat tuotantoon kivuttomammin ilman (mahdollisesti ilmeneviä) tuskallisia vaiheita ja käyttökatkoja? Älä anna jatkuvan käyttöönoton maailman pelottaa, jätä hyvästit perjantaisille käyttöönotoille ja ota kontrolli omista käyttöönotoistasi! Me autamme mielellämme tavoitteessasi. Anders tarjoaa DevOps-koulutusta, -asennuksia, automatisoituja testausasiantuntijoita ja paljon muuta.
Keskustelen mielelläni lisää DevOpsiin liittyvistä asioista (ja toki muistakin) ja voin esitellä palvelumme DevOpsin ympärillä. Voidaan verkostoitua LinkedInissä tai ole yhteydessä sähköpostilla. Lue lisää DevOpsista ja palveluistamme.
Ilmoittaudu maksuttomaan DevOps webinaariimme 23.4.2020 klo 14-15. Saat tallenteen webinaarista itsellesi! Webinaarissa saat 55 minuutissa konkreettisen kattauksen DevOps prosesseja sekä vinkkejä aloitukseen ja työkaluihin.