Teknologiat ja ohjelmistokehittäjien työskentelytavat kehittyvät nopeasti ja kaikki toimenpiteet tähtäävät tehokkaampaan työntekoon. DevOps toimintamalli ei ole uusi, mutta se on enenevissä määrin yleistyvä prosessi yrityksissä, jotka tekevät ohjelmistokehitystä itselleen tai muille. DevOps ei tule olemaan ohimenevä trendi ohjelmistokehityksessä, vaan siitä tulee normaali tapa toimia. Esittelemme blogissa kuinka DevOps prosessit kehittivät omaa toimintaamme.
Teknologiat ja ohjelmistokehittäjien työskentelytavat kehittyvät nopeasti ja kaikki toimenpiteet tähtäävät tehokkaampaan työntekoon. DevOps toimintamalli ei ole uusi, mutta se on enenevissä määrin yleistyvä prosessi yrityksissä, jotka tekevät ohjelmistokehitystä itselleen tai muille. DevOps ei tule olemaan ohimenevä trendi ohjelmistokehityksessä, vaan siitä tulee normaali tapa toimia. Esittelemme blogissa kuinka DevOps prosessit kehittivät omaa toimintaamme.
Anders ennen DevOpsia
Jo ennen DevOpsiakin olimme automatisoineet monia osia uusien projektien tuotantoon viennistä ja päivityksistä. Projekteilla oli kuitenkin taipumusta poiketa toisistaan sen verran, että täysin yhtenäisen automatisoidun mallin ylläpitäminen oli haastavaa ja ajan myötä projekteihin eksyi pikkuhiljaa manuaalisia vaiheita, jotka hidastivat prosessia ja lisäsivät projektiin liittyvää erikoisosaamista.
Käytännössä projektit vietiin tuotantoon puoliautomaattisesti valmiiden projektipohjien ja keskitetyn konfiguraatiohallinnan kautta. Tämä kuitenkin vaati, että projektin kehittäjien piti anoa oikeuksia palvelinten hallintaympäristöihin aina erikseen.
Kunnon testikierroksen puuttuminen,ennen tuotantoon vientiä, lisäsi myös virheiden mahdollisuutta. Välillä testiajot olivat lokaalisti suoritettuja ilman testiympäristöä, jolloin koodi ei aina toiminut suoraan tuotannossa, johtuen esimerkiksi kehitysympäristön ohjelmistojen eri versioista. Luotettavan testiympäristön rakennus manuaalisesti vei aikaa varsinaiselta kehitystyöltä. Välikäsiksi kaivattiin automaattisia testi- ja QA-ympäristöjä varmistamaan koodin toimivuus tuotantoympäristössä.
Kuulostaako nämä haasteet tutuilta?
Käyttöönoton riskit ja kipupisteet havaittuamme lähdimme selvittämään ratkaisua. Totesimme heti alkuun, että koko käyttöönottoprosessi pitää uudelleenrakentaa vaihe vaiheelta, sillä yksi pieni korjausliike ei auttaisi pitkässä juoksussa. Matkaamme DevOpsiin voit lukea myös Frankin blogista täällä.
TYÖVAIHEEMME DEVOPS TOIMINTAMALLIN KÄYTTÖÖNOTTOON
- Aloitimme automaattiset testaukset hyödyntämällä Travis CI:ta
- Otimme Dockerin käyttöön lokaaleihin tuotantoympäristöihin. Jokaisesta projektista rakennettiin Docker-ympäristö jossa voitiin taata, että kehitys tapahtuu aina standardoidussa ympäristössä oikeilla ohjelmistoversioilla.
- Päätimme vaihtaa Travis CI:n toiseen ratkaisuun, sillä siitä puuttui haluamiamme CD/CI ominaisuuksia. Teimme sisäisen evaluaation eri CI/CD ratkaisusta ja päätimme siirtyä GitHubista GitLabiin, koska se mahdollisti CI/CD:n hallinnoinnin samassa ympäristössä versionhallinnan kanssa.
- Koska paikallinen Docker-kehitys sujui hyvin, päätimme alkaa käyttämään sitä myös testiympäristönä. Tätä varten valitsimme Kubernetes ja Google Kubernetes Engine -palvelut sisäisiksi ratkaisuiksi Dockerin käyttämiseen.
- Jotta Kubernetesia voitaisiin käyttää mahdollisimman tehokkaasti, etsimme uusia työkaluja, jotka auttaisivat meitä toimittamaan ohjelmistoja nopeammin. Aloimme käyttämään Terraformia infrastruktuurin käyttöönottoon ja rakensimme oman työkalumme Kólgan CI/CD käyttöönottojen suorittamiseen.
Anders DevOpsin jälkeen
DevOps toimintamallin käyttöönotolla on merkittäviä etuja ohjelmistokehitykseen, tietoturvaan ja ohjelmistokehitysprojektien läpinäkyvyyteen. Automatisoitu käyttöönotto ja testaus paitsi standardoi käyttöönottoprosessia, myös varmistaa koodin laadun sekä toimivuuden tuotannossa. Kehityssykli on huomattavasti nopeampaa, jolloin saamme uusia komponentteja tuotantoon nopeasti ja yhdenmukaiset testaukset varmistavat vakaan toimintaympäristön.
Automatisoidussa testi- ja QA-ympäristössä asiakas pääsee heti tutustumaan kehitettäviin komponentteihin, jolloin kehitys on läpinäkyvää. Tämä helpottaa myös korjausliikkeiden tekoa kesken sprintinkin, jolloin vältetään turhaa kehitystyötä. DevOps toimintamallin vahvuutena on valmius reagoida nopeasti muutostarpeisiin, mikä luo huomattavaa kilpailuetua asiakkaillemme.
DevOpsin sisäistäminen organisaatiossamme vaati uusien työkalujen koulutusta ja uusien prosessien omaksuntaa, mutta kaiken kaikkiaan uusi toimintamalli otettiin avosylin vastaan. Selkeämpi käyttöönottoprosessi ja automaatiot helpottavat kehittäjien työtä sekä lisäävät yhteystyötä projekteissa. Henkilökuntamme on avoimia uusille ja paremmille työtavoille, joten DevOps toimii meillä arjessa nykyään luonnollisena osana kaikkia projekteja.

Paul Nylund (CIO) ja Frank (CTO) implementoivat DevOps toimintamallia Andersille.
Andersin DevOps tiimi
DevOps tiimimme jäsenillä on useiden vuosien kokemus erilaisten järjestelmäarkkitehtuurien suunnittelusta, testauksesta ja asentamisesta. Tiimi vastaa asiakkaidemme järjestelmäprojektien suunnittelusta ja käyttöönotosta. Asiakkaiden tarpeista riippuen hoidamme myös asiakkaiden ympäristöjen ylläpitoa ja valvontaa.
Osaavat DevOps asiantuntijamme pitävät myös koulutuksia niin sisäisesti kuin ulkoisesti. Tällä hetkellä työn alla onkin DevOps webinaarien ja koulutusmateriaalien tekoa, sillä suosittelemme kaikille ohjelmistoja kehittäville yrityksille DevOps toimintamalliin siirtymistä.
Haluaisitteko aloittaa uuden ohjelmistokehityksen aikakauden kanssamme?
Lue lisää DevOps palveluistamme.