Jos edessäsi on siirtymä yhdestä DevOps-työkalukokonaisuudesta toiseen, olen koonnut hyödyllisimmät opit sekä runsaasti käytännön esimerkkejä. Vaikean ja helpon kautta opitut asiat on muutettu käytännönläheisiksi neuvoiksi.
Kalle Sirkesalo
Field CTO
Kalle sits at the intersection of executive strategy and engineering reality. He works directly with CTOs and engineering leaders to translate business pressures — speed, compliance, ROI — into technical decisions that actually hold. His job is to make sure what we recommend is something your organization can actually execute.
Sisällysluettelo:
Millaista migraatiota suunnittelemme?Mitkä ovat onnistuneen migraation KPI-mittarit?Mistä migraatiotiimi on vastuussa?Miten tiimit siirtyvät itse uuteen ympäristöön?Miten kustannukset jaetaan?Esimerkki: täysi migraatio
Harkitsetko siirtymistä uusiin DevOps-työkaluihin? Vaikka et juuri nyt harkitsisikaan, ehkä jonain päivänä harkitset.
Nykyään saatavilla on erinomaisia all-in-one-ratkaisuja, kuten GitHub, GitLab ja Atlassian. Kuten monet muutkin, saatat kuitenkin kokea, että koko migraatioon liittyvä kokonaisuus on hieman vaikea hahmottaa.
Mitä se vaatii
Miten se tehdään
Mistä edes aloittaa
Eficodella olemme alkaneet havaita suurta muutosta asiakkaiden näkemyksissä:
10 vuotta sitten, kun aloitimme Eficode ROOT -alustamme kehittämisen, jouduimme selittämään, miksi DevOpsia kannattaa hyödyntää.
5 vuotta sitten jouduimme selittämään, miksi DevOps-työkalut kannattaa keskittää.
Tänään kerromme, miten työkalut keskitetään.
Yli 15 vuoden DevOps-kokemuksella olemme ymmärtäneet, etteivät kaikki tiedosta, kuinka vaikeaa yhdestä CI:stä toiseen vaihtaminen on.
Haluamme auttaa sinua ymmärtämään paremmin, miten säästät aikaa ja vaivaa migraation aikana sekä vältät yleisimmät sudenkuopat. Tässä blogikirjoituksessa kerromme kahdeksasta tärkeästä asiasta, jotka kannattaa pitää mielessä.
Tarkoituksemme ei ole antaa täydellisiä vastauksia, vaan nostaa esiin kysymykset, joita organisaatiosi tulisi esittää. Ne ovat niitä ”tuntemattomia tuntemattomia”: asioita, jotka on tiedettävä, jotta tietää, mitä ei tiedä.
Lue eteenpäin ja löydä oikeat kysymykset sekä huomioitavat asiat sujuvan ja onnistuneen migraation suunnitteluun.
‘migrations never fail due to technical problems’
1. Kulttuuri ei ole vielä valmis
Migraatioihin liittyy teknisiä haasteita, mutta migraatiot eivät koskaan epäonnistu niiden vuoksi.
Ne epäonnistuvat ihmisten ja kulttuurin vuoksi. Monet ajattelevat, että kyse on vain työkaluista, mutta keskeinen haaste on muutoksen johtaminen. Muutoksen johtaminen on jokaisen yrityksen kulttuurin ytimessä. Jotkut vain osaavat sen muita paremmin. Miksi tämä on niin tärkeää? Käytetään esimerkkinä todellista tapausta.
Esimerkki: GitHub Enterprise -versionhallintajärjestelmän siirtäminen on-premise-ympäristöstä pilveen
Se on yksi yksinkertaisimmista migraatioista, joita voit tehdä. Olet tehnyt kaiken tarvittavan, eikä käyttäjän kannalta mikään muutu toimintatapojen osalta. Jotkin asiat sujuvat jopa helpommin kuin ajattelit, eikä migroitujen asetusten kanssa tarvitse huolehtia. Jokaisen GitHub-käyttäjän on kuitenkin muutettava yksi asia omassa ympäristössään: repositorion URL-osoite. Tämä URL-osoite löytyy myös kaikista CI/CD-töistä.
Mitä siis teet? Kirjoitatko DevOps-pipelinen logiikan uudelleen tukemaan tätä?
Kyllä, se voidaan tehdä – kuten me olemme tehneet. Mutta entä SSH-todennuksen hash-tarkistukset? Niiden voisi ajatella toimivan, mutta valitettavasti eivät: ne on hyväksyttävä manuaalisesti.
Tämä johtaa siihen, että tiimejä on ohjattava ja patisteltava paljon. Keskusteluissa saatetaan todeta esimerkiksi: ”Kuka maksaa menetetyn ajan?”, ”Myöhästyimme tärkeästä välitavoitteesta” ja niin edelleen. Olet menettänyt organisaation luottamusta, koska et onnistunut johtamaan yhtä yksinkertaista päivitystä, joka edellytti käyttäjiltä toimia!
Tässä oli kyse vain Git-repositorioiden migroinnista. Miltä luulet Jiran käyttäjistä tuntuvan, kun haluat siirtää heidät GitLabiin?
Vinkki: Migraatioita tehdessäsi kartoita integraatiopisteet, jotta saat luettelon järjestelmistä, joihin muutos vaikuttaa, sekä päivitettävien repositorioiden URL-osoitteet.
Ratkaisuksi annamme asiakkaillemme yleensä seuraavat neuvot:
Kokoa kaikki sidosryhmät yhteen ja kerro heille hyvissä ajoin tulevasta, jotta voit tarjota ohjausta ja liiketoiminnan tukea. Kokeneet työntekijät voivat selittää migraation syyt.
Jatkuva viestintä on avainasemassa koko prosessin ajan – myös ylläpidon jälkeisen vaiheen jälkeen.
Liiketoiminnan tukeminen edellyttää kannustimien ymmärtämistä: migraatiolle on laadittava hyvä liiketoimintaperuste ja prioriteettien on oltava selkeät. Jos esihenkilösi kysyy: ”Mitä säästämme tällä?”, sinun pitäisi pystyä vastaamaan kysymykseen.
Teimme laskurin säästöjen arviointiin. Laskuri perustuu Eficoden kokemukseen ja Eficode ROOT -ratkaisuun, mutta se antaa varsin hyvän kuvan tilanteesta.
Koska nämä keskustelut voivat olla hankalia, migraation toteuttaminen ulkopuolisen yrityksen avulla voi joskus olla helpompaa, sillä sinun ei tarvitse kantaa vastuuta yksin. Olemme nähneet yrityksiä, jotka eivät kerro henkilöstölleen asiasta ja pahoittelevat vasta, kun jokin menee pieleen, koska ne ajattelevat sen olevan yhtä tehokasta. Tämä ei kuitenkaan ole paras tapa viestiä yrityksessä, ja se johtaa yleensä huonompiin lopputuloksiin kuin avoimuus. Jos tarvittavien tapaamisten järjestämiseen kuluu enemmän aikaa kuin sidosryhmille anteeksipyytämiseen, se ei todennäköisesti kannata.
2. Ihmiset eivät pidä muutoksesta
Nyt kun olemme käsitelleet organisaatiokulttuurin aiheuttamia muutoksia, puhutaan siitä, miten ne vaikuttavat yksilöihin. Organisaation vahvat vaikuttajat voivat muodostaa haasteen. He ovat yleensä näiden työkalujen tehokäyttäjiä, joilla on vahva tekninen ja/tai sosiaalinen asema organisaatiossa. He pitävät käyttämistään ja ylläpitämistään työkaluista, eivätkä siksi näe syytä korvata työkaluja, joiden huolelliseen käyttöönottoon he ovat investoineet niin paljon aikaa.
Uuden työkalun opettelun on oltava heidän aikansa arvoista, ja heidän aiempi kokemuksensa on saatava hyödyksi uuden työkalun yhteydessä.
Heistä on tehtävä uuden työkalun puolestapuhujia ja muutoksen edistäjiä. Tee näin:
Selvitä heti, keitä nämä henkilöt ovat
Ota heidät mukaan mahdollisimman varhaisessa vaiheessa
Näytä, miten nykyiset ongelmat ratkaistaan uudella työkalulla
Pyydä heiltä neuvoa siihen, mihin migraatiota kannattaa laajentaa seuraavaksi.
Tämä on erittäin tehokas tapa saada heidät mukaan puolustamaan uutta työkalua tiimeille. Kun he ymmärtävät työkalun, he omaksuvat sen eivätkä pelkää muutosta. Sen sijaan heistä tulee parhaat lähettiläänne migraatiossa! Muutoksen pelkoa voi usein lieventää koulutuksella ja keskusteluilla työkalujen nykyisten käyttäjien kanssa.
Vinkki: Ota tehokäyttäjät mukaan päätöksentekoon, jotta he voivat kertoa näkemyksistään.
Esimerkki: Jenkinsin perinpohjainen tarkastelu
Yksi asiakkaistamme suhtautui hyvin epäilevästi siihen, pystyisimmekö auttamaan heitä työssään ja työkalujensa hostingissa. Keskustelimme heidän työkuormansa osittaisesta keventämisestä, mutta he pitivät siihen kuluvaa työmäärää vähäisenä.
Kävimme läpi, miten uusi työkalu Jenkins toimii ja miten heidän on tarkistettava jokainen lisäosa. Jos jokin hajoaa yöllä, heidän on herättävä korjaamaan se. Kävimme läpi järjestelmän sekä päivittäisen lisätyön määrän, jota järjestelmän toiminnassa pitäminen heiltä vaati.
He halusivat todellisuudessa rakentaa järjestelmälleen paremman testiarkkitehtuurin päivittäisen tulipalojen sammuttelun ja korjaamisen sijaan. Keskustelimme siitä, miten olemme ratkaisseet nämä ongelmat aiemmin. Sen jälkeen he kysyivät, voisimmeko ottaa myös muutamia heidän muita järjestelmiään ylläpidettäväksi, jotta he voisivat keskittyä luomiseen ja koodin kirjoittamiseen. Kuulluksi tuleminen oli avainasemassa, jotta he ymmärsivät oman lähtötilanteensa.
3. Huomio ei kohdistu oikeisiin kysymyksiin
Olemme löytäneet lähettiläämme, ja kulttuurimme suhtautuu migraatioon yhä myönteisemmin. Kaiken pitäisi olla valmista, eikö niin? Ratkaistaan vain ne hankalat tekniset ongelmat!
Ei vielä. Tarvitsemme selkeän suunnitelman.
Meidän on vastattava migraation viiteen kysymykseen, jotka määrittävät onnistumisemme. Näin varmistamme, että kaikki ovat samalla kartalla migraation tavoitteista. Toimimme kuten ohjelmistoprojekteissa: meidän on pysähdyttävä varmistamaan, että kaikki ymmärtävät, miksi teemme tätä ja mitä kohti olemme menossa.
Kysymyksiä, որոնք kannattaa esittää migraation suunnittelussa:
Millaista migraatiota suunnittelemme?
Mitä dataa meidän odotetaan migroivan?
Odotammeko kehittäjille täysin automatisoitua migraatiota vai sitä, että he tekevät itse paljon muutoksia?
Migroimmeko saman työkalun toiseen instanssiin vai täysin uuteen työkaluun?
Jos kyseessä on uusi työkalu, mitä odotamme muuttuvan nykyisissä työtavoissa?
Mitkä ovat onnistuneen migraation KPI:t?
Meidän on määriteltävä onnistuneen migraation KPI:t.
Mitä pidämme onnistumisena: että kaikki käyttäjät on migroitu, tiimit ovat tyytyväisiä uusiin työkaluihin, sykliajat lyhenevät tai kustannukset pienenevät?
Miten arvioimme näitä ja mille tasolle asetamme tavoitteet?
Kun olet vastannut näihin kysymyksiin, voit kysyä, millainen migraatiotiimin kokoonpanon tulisi olla, jotta se voi saavuttaa nämä KPI:t. Tiimityön vaikein osa on saada kaikki samalle sivulle. Kun asetat KPI:t, mieti siis, miten ne vaikuttavat eri sidosryhmiin.
Jos tavoittelet parasta mahdollista laatua, valitse KPI:t, jotka vaikuttavat migraation laatuun, kuten:
Tukipyyntöjen määrä (tavoitteena nolla)
Loppukäyttäjiltä vaadittavan työn määrä (jonka tulisi olla mahdollisimman pieni)
Vaikutus liiketoimintaan
Uuden järjestelmän käytettävyys (käyttäjätyytyväisyyskyselyn avulla).
Jos tavoittelet mahdollisimman pieniä kustannuksia, käytä KPI:itä, jotka mittaavat:
Projektin kesto
Ominaisuuksien vastaavuus aiemmin käytössä olleiden järjestelmien kanssa
Kaksi viikkoa migraation jälkeen avoinna olevat tukipyynnöt.
Nämä vaikuttavat siihen, mitä migraatiotiimi optimoi.
Mistä migraatiotiimi on vastuussa?
Nyt kun tiedät, mitä migraatiotiimimme priorisoi, on aika kysyä: ”Mitä tiimeiltä tulisi edellyttää?” Määrittele tämä KPI:idesi pohjalta. Jos tavoittelet pienimpiä kustannuksia, manuaalista työtä tarvitaan enemmän kuin silloin, jos käytät kuusi kuukautta työkalujen kehittämiseen, jotta kaikki voidaan migroida kerralla.
Mieti siis tarkkaan, mitä voit odottaa tiimeiltäsi.
Miten tiimit migroivat uuteen ympäristöön?
Näemme usein suuria investointeja tehtäviin, jotka tiimit voisivat hoitaa hyvin helposti itse ja jotka heidän voisi olla jopa järkevää hoitaa itse. Esimerkiksi CI/CD-töiden siirtäminen uuteen ympäristöön ja samalla vanhan roinan siivoaminen.
Yleensä ei ole järkevää migroida jotain, mitä ei käytetä – varsinkaan, jos se ei koskaan edes toiminut tiimin odottamalla tavalla. Joskus tiimit kuitenkin haluavat siirtää CI/CD:nsä yhdellä kertaa. He eivät halua koskea asiaan, joka toimii.
Miettikää siis, miten voitte kannustaa tiimejä migraatioon ja luoda sille painetta. ”Tämä palvelu suljetaan kuuden kuukauden kuluttua” on aina toimiva keppi, mutta onko se tehokas omassa organisaatiossamme?
Olen nähnyt monia organisaatioita, jotka ilmoittavat käyttäjilleen palvelun lakkauttamisesta. Koska ihmiset kuitenkin tietävät, ettei lakkautusta tapahdu, he jatkavat vanhojen ratkaisujen käyttöä. Tiimit saattavat jopa käyttää ympäristöjä, jotka ”tapettiin” jo vuosikymmeniä sitten.
Jos haluatte palauttaa kipupisteen: kohdistakaa kustannukset tiimeille, jotka käyttävät sitä edelleen. Yleensä siinä vaiheessa tiimi migroi yllättävän nopeasti uuteen järjestelmään. Muistakaa kuitenkin, että jokainen organisaatio on erilainen.
Hyvä, teillä on siis KPI:t, vaatimukset ja migraation määrittely. Edessänne on silti kaikkein vaikein kysymys. Sellaista, johon ette todennäköisesti pysty vastaamaan yksin ja jota esihenkilönne välttelee kuin ruttoa. Jos ette kuitenkaan ratkaise sitä, heitätte hiekkaa luisteluradallenne.
Miten kustannukset jaetaan?
Migraatiolla on suoria kustannuksia, kuten lisenssit ja siihen käytetty työ. Se on selvää.
Entä epäsuorat kustannukset ja vaihtoehtoiskustannukset? Molemmat vaikuttavat edellä mainittuihin asioihin, ja siksi määrittely alun perin laadittiin. Sitä tarvitaan, jotta kukaan ei estä migraatiota.
Tarvitsette selkeän suunnitelman siitä, miten ilmoitatte jokaiselle tiimille, että tämä projekti on toteutettava. Vaihtoehtoisesti migraatiotiimille on kohdistettava tarvittavat kustannukset, jos nämä kustannukset aiheuttavat viivästyksiä. Kuka maksaa arvokkaasta kehitysajasta, joka jäi käyttämättä migraation aikana? Vastauksen pitäisi olla selkeä, ja koko johtoryhmän tulisi tukea sitä. Vähintäänkin sponsorinne on ymmärrettävä, että tämä kysymys tulee hänen pöydälleen. Kun kerrotte asiasta kaikille jo ennen kuin he ehtivät kysyä, sidosryhmänne saavat teistä paremman kuvan.
Esimerkki: täysi migraatio
Onnistuneessa migraatiossa, jonka toteutin muutama vuosi sitten, asiakas sanoi: ”Haluamme täyden migraation, jotta meidän ei tarvitse tehdä mitään.” Ja niin me teimme:
Valmistelimme skriptit git-repositorien päivittämiseksi uusilla URL-osoitteilla.
Määritimme Artifactoryn URL-uudelleenohjaukset korvautumaan automaattisesti uusilla, turvallisilla uudelleenohjauksilla.
Siirsimme työt on-premise CI/CD:stä pilveen, testasimme ne ja valmistelimme ne toimimaan kuten aiemmin. Valmistelimme myös Jiran ja Confluencen migraation Oracle-tietokannoista PostgreSQL:ään.
Samalla siirsimme koko infrastruktuurin AWS:ään.
Työn kustannukset olivat paljon asiakkaan odotuksia suuremmat, sillä ympäristökohtainen koodi piti suurelta osin kirjoittaa uudelleen. Näin pystyttiin toteuttamaan URL-uudelleenohjaukset, jotka estivät asioiden rikkoutumisen, ja samalla muuttamaan kaikki liikenne muodosta http://address:port muotoon https://service. Asiakas oli pieni, joten oletimme, ettei heillä ollut aikaa tähän. Kun kuitenkin kuuntelimme palautetta siitä, mikä meni pieleen, he sanoivat:
”Olisimme voineet vaihtaa nuo URL-osoitteet itse. Se olisi ollut kehittäjillemme erittäin nopea osa heidän normaalia työtään.” Kun emme määritelleet, ”mitä tiimit tekevät?”, päädyimme tekemään paljon enemmän työtä kuin asiakas odotti. He ovat edelleen tyytyväinen asiakkaamme ja luottavat meihin, mutta opimme läksymme. Nykyään ohjaamme asiakkaitamme aina määrittelemään tärkeät asiat, joiden ratkaisemista he odottavat meiltä, jotta he varaavat niihin myös budjetin.
Kerrataan vielä migraatioon liittyvät kysymykset:
Millaista migraatiota suunnittelemme?
Mitkä ovat onnistuneen migraation KPI:t?
Mistä migraatiotiimi on vastuussa?
Mitä tarkalleen haluamme tiimien migroivan? Onko migraatiolle kannustimia tai sitä vastaan vaikuttavia tekijöitä?
Miten kustannukset jaetaan? Kaikki kolme: suorat, epäsuorat ja vaihtoehtoiskustannukset.
4. Teidän on uudelleenmääritettävä radikaalisti
Aina kun vaihdat käyttämääsi työkalua, myös konfiguraatiot voivat muuttua merkittävästi, sillä työkalut toimivat hyvin eri tavoin. Määrittele siis suunnitteluvaiheessa aina, mitä voidaan menettää. Kaikkea ei ole helppo toteuttaa uudelleen. Monia toimintoja voi yleensä toteuttaa, mutta siihen voi kulua paljon työtä toiminnon hyötyyn nähden.
Esimerkiksi käyttöoikeustasoja ei yleensä voi toistaa täsmälleen, sillä joissakin työkaluissa käyttöoikeustasot ja roolit ovat paljon tarkempia kuin toisissa. Sinun on selvitettävä etukäteen, miten käyttöoikeudet vastaavat toisiaan ja mitä käyttöoikeuksia tiimit tarvitsevat oletuksena.
CI/CD:n osalta en ole törmännyt yhteenkään organisaatioon, jossa buildit tai käyttöönotot tehtäisiin vain yhdellä tavalla. Olen jopa nähnyt organisaatioita, jotka tarjoavat valmiita käyttöönottotöitä, mutta joissa tiimien välillä on silti eroja.
Vinkki: tee yleiskuvaus nykytilanteesta. Selvitä, kuinka moni töistä on määritelty koodina ja kuinka moni käyttöliittymässä, jos työkalu tukee työn konfigurointia käyttöliittymässä.
Todennäköisesti olet siirtymässä työkaluun, joka tukee vain as-a-code-lähestymistapaa, tai haluat siirtää kaikki työt koodiin. Siksi on tärkeää selvittää, kuinka monessa tapauksessa kyse on vain syntaksin vaihtamisesta ja missä tiimeille pitää opettaa täysin uusia toimintatapoja. Niiden on opittava, että CI/CD kuuluu repositorioon.
Valmistele yhdessä lähettiläidesi kanssa hyvät ohjeet yleisimmille ohjelmointikielille ja käyttötapauksille. Varaudu myös massamigraation vielä tuntemattomiin haasteisiin: opit, miten yksinkertaisinkin konfiguraatiomuutos voi kohdata myrskyisiä vesiä.
Esimerkki: Jenkinsfile-parserin käyttäminen GitLabissa
Kuvittele tilanne: kaikki on Jenkins-töissä, ja siirryt GitLabiin käyttämällä Jenkinsfile-parseria, jotta GitLab suorittaa Jenkinsfilet samoilla palvelimilla ja samalla konfiguraatiolla. Asioita rikkoutuu silti, sillä kaikki ei toimi kaikissa tilanteissa. Esimerkiksi monet työt on aiemmin rakennettu lähettämällä binääri Jenkins masterille.
Jos tällainen binäärin käyttöönotto on käytössä eikä binääriä ole missään muualla, tulevaa GitLab-ratkaisua on erittäin vaikea toteuttaa. Tämä johtuu siitä, että binäärit liikkuvat töiden välillä eri tavalla. Siksi jotkin työt on uudistettava kokonaan. Jos ne muodostavat yhdessä toimivan työketjun, ne pitäisi suunnitella uudelleen yhdeksi pipelineksi. Se voi olla haastavaa, sillä alkuperäiselle suunnittelulle on yleensä ollut syynsä.
Opettele ensin työskentelemään uusilla työkaluilla ja pohdi vasta sitten, mitä kannattaa tehdä. Älä yritä tehdä migraation aikana liikaa. Et pysty kattamaan kaikkia skenaarioita, joten keskity mieluummin valtaosaan kuin yritä ratkaista kaikki monimutkaiset tapaukset.
Yleensä tavoitteena on varmistaa, että 80 % ihmisistä saa hyvän käyttökokemuksen. Entä loput? Siksi teit kolme ensimmäistä vaihetta: jotta voit purjehtia sameiden vesien läpi hukkumatta.
Tärkein vinkkimme on: älä yritä tehdä liikaa. Tee yleisiä oletuksia ja varaudu korjaamaan loput migraation jälkeen.
5. Kannattaako automatisoida vai ohjata ihmisiä?
Olet nyt kartoittanut työkalujen väliset erot ja hankkinut työkalut organisaatiollesi. Seuraavaksi on aika ratkaista suuri kysymys: kuinka paljon automatisoidaan ja kuinka paljon ihmisiä ohjataan? Ohjaavan periaatteen tulisi olla se, miten työskentelyyn vaikutetaan oikein.
Kysy siis seuraavat kysymykset:
Mitä dataa tai toiminnallisuuksia sinun on tuotava mukanasi uuteen järjestelmään?
Mitä dataa tai toiminnallisuuksia voit pitää vaihtoehtoisena tai lisätavoitteena?
Mitkä uuden työkalun ominaisuudet otat käyttöön oletuksena? Olivatko nämä ominaisuudet käytössä vanhassa ympäristössä?
Kun tiedät, mitä on tehtävä ja kuka sen tekee, on aika aloittaa varsinainen toteutusbacklogi. Se, mitä automatisoit ja mille luot ohjeistukset, riippuu siitä, kuinka laajasti työkalun ominaisuutta käytetään. Huomioi myös, kuinka paljon aikaa tiimeiltä kuluisi sen käyttöönottoon. Mieti lisäksi, edellyttävätkö säädökset kyseisten ominaisuuksien käyttöönottoa.
XKCD on tehnyt hienon kuvituksen, joka havainnollistaa, kuinka paljon aikaa ihmiset voivat käyttää rutiinitehtävien tehostamiseen ja silti säästää aikaa viiden vuoden aikana.
6 000 kehittäjän organisaatiossa pieninkin automaatio voi säästää valtavan määrän tunteja. Esimerkkejä ovat URL-osoitteiden rikkoutumisen ja taaksepäin yhteensopivuusongelmien välttäminen sekä se, että CI-pipelineihin lisätään tietyt asiat automaattisesti.
Mitä laajemmin voit toteuttaa muutoksen, sitä enemmän aikaa säästät. Esimerkiksi Git-URL-osoitteen muuttaminen 6 000 kehittäjän organisaatiossa voi kestää 10 minuuttia, mutta työntekijöiltä siihen kuluu yhteensä 60 000 minuuttia. Teoriassa tämä tarkoittaa 1 000 tuntia lisätyötä.
Todellisuudessa muutos tehdään todennäköisesti samalla, kun ajatellaan jotain muuta tehtävää tai luetaan aamun sähköposteja. Mutta jo 10 % näistä tunneista tarkoittaisi 100 tuntia menetettyä työaikaa. Siksi kaikkiin vaikuttavien asioiden automatisointi on yleensä järkevä valinta.
Myös Gitin haarautumis- ja yhdistämisstrategiat vaikuttavat suoraan työntekijöihisi. Et siis halua käyttää vääriä strategioita jokaisessa projektissa. Pohdi siksi seuraavaa:
Miten automaatio vaikuttaa loppukäyttäjään
Missä ja kuka käyttäisi rakennettua automaatiota
Miten varmistamme, että oikeat asetukset kopioituvat projekteihin
On myös erittäin tärkeää ymmärtää, mitä CI/CD-agentista, runnerista tai actionista voi automatisoida. Kysy:
Millaista räätälöintiä sallimme?
Miten mahdollistamme sen?
Kuka hallinnoi sitä tulevaisuudessa?
Missä vaiheessa tiimit saavat suurimman hyödyn, vaikka esimerkiksi kaikkien säädösten ei vielä tarvitse olla käytössä?
Hallinnoimmeko näitä tiimien puolesta vai hallinnoivatko tiimit ne itse?
Suosittelemme yleensä hankkimaan näiden hostaukseen liittyvän asiantuntemuksen ammattilaispalveluna, sillä agentit, runnerit ja actionit aiheuttavat usein yllätyksiä. Niiden muuttaminen migraation yhteydessä johtaa siksi lähes aina haasteisiin.
Esimerkki:
Windowsissa C#:lla voit todentaa SQL Server -tietokantaan AD-oikeuksilla. Tätä varten palvelimen on:
oltava yhdistettynä AD:hen, jolloin uudelleenkäyttöönottoja on vaikea automatisoida
päästävä käsiksi mainittuihin tunnistetietoihin, mikä herättää tietoturvahuolia siitä, kenellä on pääsy agentteihin, runnereihin ja actioneihin
Nämä asiat voidaan selvittää ja käsitellä tiimin kanssa etukäteen. Monimutkaisuuden vuoksi agenttien, runnerien ja actionien voi olla tarpeen pysyä tiimin käytössä ja manuaalisesti ylläpidettävinä migraation ajan sen sijaan, että ne siirrettäisiin automaattisesti skaalautuvaan ja ylläpidettävään pilviympäristöön.
Älä yritä korjata näitä pooleja migraation aikana – se on mahdotonta. Pyri pitämään järjestelmä mahdollisimman samanlaisena ensimmäisten laajojen migraatioiden ajan ja keskity niihin vasta sen jälkeen. Se vaatii lisätyötä, mutta säästää kokonaisuudessa aikaa.
Joskus ajattelemme automaation ratkaisseen ongelmamme, mutta todellisuudessa asiat eivät koskaan ole niin suoraviivaisia. Mieti väitettä: Kaikki ympäristömme ovat jo kontitettuja ja dokumentoituja – miksi meidän pitäisi välittää?
Tämä tarkoittaa todennäköisesti, että voit siirtyä keskitetysti hallinnoidulle agenttialustalle, esimerkiksi ajaa kaikki tiimien työkuormat yhtenäisessä Kubernetes-ympäristössä. Se tarkoittaa kuitenkin myös sitä, että verkotukset on edelleen suunniteltava ja valmisteltava.
Asioiden muuntaminen Kubernetesille kartoittamatta vanhan ympäristön vaatimuksia on riskialtista, vaikka ne olisi kontitettu Dockerilla. Jos siirryt keskitetysti ajettaviin Kubernetes-agenttipooleihin, ota ne käyttöön pilvessä aina kun mahdollista.
Buildien ja käyttöönottojen hostaus sekä on-premises Kubernetes ovat erittäin kalliita, eikä niiden skaalautuvuus vastaa pilveä. Ympäristön kustannusten ja virhealttiuden vähentämiseksi taustalla olevaa infrastruktuuria kannattaa jatkuvasti ajaa alas.
Automaatio on ystäväsi, mutta kaiken automatisointi ei aina kannata. Keskity aiemmin määrittelemiimme kriittisiin asioihin. Mieti: ”Tarvitsevatko käyttäjämme tätä todella, vai voisivatko he hoitaa tämän itse?” Jos koet sen silti tarpeelliseksi, automatisointia kannattaa ehdottomasti selvittää.
6. Mieti, miten migroit artifactit
Artifactien hallintaohjelmiston vaihtaminen vaikuttaa aluksi helpolta. Näiden binäärien migrointi on kuitenkin usein työlästä monien toisiinsa kytkeytyvien asioiden vuoksi. Sinun on kartoitettava, mitä repository-tyyppejä käytössäsi on, jos niitä on.
Monet CI/CD-työkalut mahdollistavat oman levynsä väliaikaisen käytön tähän tarkoitukseen. Tämä aiheuttaa migraatiossa usein ongelmia, koska binääriä ei tallenneta odottamallasi tavalla. Jos esimerkiksi siirryt staattisista agenteista dynaamisiin, jotka tyhjentävät levyn jokaisen buildin jälkeen estääkseen turhan kertymisen, voit joutua vaikeuksiin.
Tämä tekee näiden binäärien migroinnista riskialtista. Ei riitä, että tarkistat uusien järjestelmien tukevan x-, y- ja z-teknologioita, vaan on kysyttävä myös: ”Tukeeko se remote- ja virtual-repositoryja?” Näin voit esimerkiksi luoda remote-repository-yhteyden npm.org:iin ja yhdistää sen muihin repositoryihisi virtual repositoryjen avulla.
Kysy tämä:
Entä binäärien rakenteet? Myös niitä voi mukauttaa monissa työkaluissa.
Oletko käyttänyt julkaisuja binäärijärjestelmässä?
Miten käytät niitä tulevassa järjestelmässä?
Ennen migraation aloittamista on selvitettävä yllättävän monta asiaa, kuten tukeeko työkalu tarvittavia ominaisuuksia.
URL-muutokset
Kaikki binäärin URL-osoitteeseen tai käyttöönoton kohteeseen tekemäsi muutokset vaikuttavat kaikkiin tehtäviin, jotka käyttävät määrittämääsi binäärirepositoriota. URL-osoitteen muuttaminen vaikuttaa kaikkiin kyseistä binääriä käyttäviin tehtäviin. Tämä tarkoittaa, että URL-osoitteet on etsittävä ja korvattava tai ne on jotenkin yhdistettävä proxyjen kautta, jotta binäärit ovat käytettävissä kuten aiemmin. Tiimillämme on aiemmin ollut paljon haasteita porttien poistamisessa ja https:n lisäämisessä artefakteihin. Ne ovat nykyjärjestelmien vakiotietoturvaominaisuuksia, mutta niiden käyttöönotto niin, että CI/CD toimii edelleen, ei ole helppoa.
DevSecOps-putket
Entä DevSecOps-putkenne? Miten ne integroituvat uuteen työkaluun? Esimerkiksi Jfrog Xray toimii vain Jfrog Artifactoryn kanssa, joten DevSecOps-työkalu on vaihdettava toiseen. Kyse ei siis enää ole yhden työkalun, vaan monien työkalujen vaihtamisesta.
Samalla on selvitettävä, mitä etärepositorioita kannattaa tarjota, sillä monet tiimit saattavat käyttää julkista internetiä suoraan eri syistä. Binäärienhallintajärjestelmän tulisi tarjota niille pienempi viive ja parempi saatavuus.
Binääritallennustilat
Binääritallennus ei ole vain kehittyneempi jaettu levy. Siinä on paljon hyödyllisiä ominaisuuksia, jotka voivat muodostua ongelmaksi, jos esimerkiksi haluat migroida kokonaan GitLabiin, sillä monia ominaisuuksia ei vielä ole saatavilla itse työkalussa.
Vaihtoehtoja on: voit esimerkiksi arkistoida vanhat tiedot kustannusten säästämiseksi ja korjata asioita vasta ongelmien ilmetessä. Voit myös siirtyä uuteen järjestelmään säilyttäen vanhan, ottaa uusia ominaisuuksia käyttöön vähitellen ja selvittää, mitä ominaisuuksia edelleen tarvitset. Tarvittavista ominaisuuksista riippuen voit ehkä tehdä muitakin järjestelyjä päästäksesi eroon kehittäjille ylläpitämästäsi kalliista järjestelmästä.
Esimerkki: Docker-etäproxyn valinta
Yksi asiakkaistamme päätti siirtää kaiken GitLabiin ja poistaa kaikki muut ratkaisut putkistaan. Tämä edellytti laajaa selvitystyötä siitä, miten binäärit voidaan tarjota GitLabista ja millaisia rajoituksia siihen liittyy. Päädyimme siihen, että heidän tiiminsä käyttivät Dockeria paljon ja tarvitsivat Docker-proxyn.
Ratkaisumme oli noudattaa GitLabin ohjeistusta ja ottaa käyttöön Docker Hubin Docker-etäproxy, jotta imageja voitiin käyttää GitLabin kanssa maksamatta vanhan järjestelmän lisenssistä. Näin heidän DevOps-kustannuksensa pienenivät hieman.
En voi varsinaisesti kutsua tätä onnistumiseksi, sillä säästöt olivat hyvin pienet verrattuna projektiin, jossa binäärienhallinta siirrettiin pelkästään GitLabiin. Muutoksen kustannusten takaisin saaminen vie vuosia. Siksi ehdotan usein seuraavaa:
säilytä binäärienhallintaohjelmisto ja siirrä se ehkä vain pilveen
integroi se S3-bucketeihin tai vastaaviin, jotta käytössä on edullista tallennustilaa
siirry binäärienhallinnassa optimoidumpaan arkkitehtuuriin
Kustannuksia on helpompi pienentää muilla alueilla kuin binäärienhallinnan lisensseissä, sillä kilpailu pitää niiden hinnat varsin matalina.
7. Vanhat putket
Olet nyt viimein valmis pohtimaan vanhojen ratkaisujen siirtämistä uusiin järjestelmiin ja sitä, miten tiimi alkaa käyttää uusia työkaluja. Olet käynyt läpi politiikan ja työtapojen muutokset, ja voit viimein kysyä:
Miten siirrämme vanhat työkalut uuteen järjestelmään?
Kuulemme usein tiimeistä, jotka siirtyvät Jenkinsistä tai Teamcitystä GitLabiin tai GitHubiin yhden alustan hyötyjen vuoksi. He etsivät tähän ihmeratkaisua. Ensimmäiseksi kysymme heiltä: ”käytättekö Jenkinsfileja tai Teamcity YAML:ää?” Vastaus on yleensä: ”osa tiimeistämme käyttää”.
Tämä tarkoittaa, että käytössä on käsin tehtyjä ClickOPS-tehtäviä, jotka pitäisi kirjoittaa uudelleen näille työkaluille. Tehtävät tehtiin aikana, jolloin CI as Code oli vielä merkittävä konsepti, mutta sitä ei ollut vielä otettu käyttöön. Siksi käsin tehdyt putket on kirjoitettava kokonaan uudelleen, sillä niitä ei voi helposti migroida putkimalliin.
Laadi seuraavaksi lista seuraavista asioista:
mitä jobeissa on muutettava, jotta ne toimivat
miltä uusi syntaksi näyttää
miten Maven, NPM, Nuget tai muut paketinhallinnat toimivat uudessa työkalussa
Migraation aikana sinun on laadittava tiimille demoja, esimerkkejä ja dokumentaatiota. Ne auttavat tiimiä kirjoittamaan jobinsa uudelleen ja korjaamaan niitä, kun jokin alkaa mennä pieleen.
Voit ehkä siirtää joitakin jobeja uudelle alustalle rakentamalla kiertoratkaisuja, kuten ajamalla Jenkins corea agentissa, jolloin Jenkinsfileja voi ajaa GitLab runnerissa. Tätä voi käyttää lähinnä suurten määrien migrointiin, ja sitä tulisi pitää väliaikaisena ratkaisuna, joka kannustaa tiimejä kirjoittamaan jobit uudelleen.
Uudelleenkirjoittaminen on tarpeen SAST- ja DAST-ominaisuuksien käyttöönottoa varten. Jos et rakenna tällaisia osia jobiin:
Miksi siirrät kaiken uudelle alustalle? Jos et pyri hyötymään DevOps-yhteisöjen saavutuksista, mitä yrität saavuttaa?
Palataan tämän blogin alkuun: jos et aio siirtää mitään uudelle alustalle, onko sinulla todella liiketoimintaperustetta vai muutatko vain muutoksen vuoksi?
Työkalujen migraatio edellyttää usein siirtymistä uudelle alustalle ja refaktorointia uusien ominaisuuksien hyödyntämiseksi. Lisäksi yksikään työkalu ei käytä samanlaista syntaksia, joten tuotteeseen siirtyminen ja siitä pois siirtyminen on kallista työtä. Siksi monet yritykset välttelevät sitä. Lopputulos on yleensä vaivan arvoinen: migraation jälkeen ihmisiä on helppo siirtää työkalujen ja tuotteiden välillä, kun tiimit käyttävät samoja työkaluja ja prosesseja.
Migraatiota varten on suunniteltava, miten poikkeustilanteita hallitaan ja niissä autetaan, miten etenemistä seurataan ja miten järjestelmät pidetään tiimien käytössä. Migraatiot edellyttävät yleensä erittäin tiukkaa projektinhallintaa sekä seuraavien asioiden seurantaa:
Kuka ajaa edelleen jobejaan ja miksi?
Mitä meidän on ratkaistava?
Jotkut tiimit sanovat, että jokin ominaisuus puuttuu tai sen toteutustapa estää heidän työnsä. Putken voi rakentaa monella tavalla, eikä yhdenkään niistä pitäisi tarkoittaa 400-rivisen Groovy-skriptin kirjoittamista pelkän prosessiongelman ratkaisemiseksi.
Älä yritä ratkaista kaikkea CI/CD:llä, vaan rakenna luottamuksen kulttuuria. Jos et voi luottaa työhösi ja sen vaiheisiin, pysähdy tarkastelemaan, mitä ja miten teet. Jos et ole valmis luottamaan putkiisi ja toimintatapoihisi, mihin voit luottaa DevOpsissasi?
Aloita keskustelemalla ominaisuudesta tiimin kanssa ja kysymällä: ”miksi”.
Miksi emme luota testeihimme?
Miksi tämä vaatii ihmisen vuorovaikutusta?
Varmista, että tiimiin luotetaan. Jos näin ei ole, ette tee DevOpsia.
Jos käytätte CI/CD:tä käyttöönottojen nopeuttamiseen, antakaa näiden tiimien pysyä siinä työkalussa. He eivät muutu, riippumatta siitä, mitä työkaluja otatte heille käyttöön. Siirtäkää Git-repositorio ja jättäkää CI/CD sinne. Build-työkalun vaihtaminen vain tiimin muuttamisen vuoksi toimii harvoin.
Mutta jos he ovat valmiita muuttumaan ja hyväksymään heille osoittamasi luottamuksen, on aika luottaa heihin. He pärjäävät kyllä.
8. Tarvitset uusia dashboardeja ja näkymiä
Ensinnäkin unohda dashboardien ja näkymien siirtäminen sellaisenaan. Ne eivät toimi uudessa työkalussa kuten vanhassa. Rakenna ne uudelleen uuden työkalun tarpeisiin. Mieti migraation aikana esimerkiksi: ”Tarvitsemmeko todella dashboardin, joka näyttää vihreää tai punaista, vai voimmeko tehdä siitä etätyöhön paremmin sopivan?”
Dashboardit voivat näyttää vain sen, mitä pyydät niiden näyttävän, käyttämälläsi datalla. Et voi näyttää näkymää datasta, jota sinulla ei ole. Tiimisi on toteutettava dataflowt, joten mieti, miksi haluat kunkin dashboardin.
Dashboardit ovat kaksiteräinen miekka. Jos tiimisi keskittyvät parantamaan dashboardin lukuja, vaarana on, että dashboard alkaa tehdä päätökset puolestasi.
Esimerkiksi eräällä asiakkaalla aloimme mitata julkaisuja Jirassa. Pian tämän jälkeen toteutimme tiimille automaattisen julkaisujen luomisen ja sulkemisen sen perusteella, mitä tikettejä oli siirretty Done-tilaan tietyn ajanjakson aikana. Näin he pystyivät näyttämään julkaisunsa mittarissa ilman, että ominaisuutta tarvitsi oikeasti käyttää. Mittari parani kymmenkertaiseksi, mutta se ei todellisuudessa ratkaissut tiimin ongelmia.
Toinen dashboardien ongelma on se, että jos tiimi ei välitä dashboardista, sitä ei katsota. Sen sijaan, että muutat kaiken dashboardiksi, pysähdy miettimään: ”Mitä todella tarvitsemme?” ”Mitä tällä yritämme saavuttaa?”
Data on vain yhtä hyvää kuin sen jäsentäminen. Kuten sanotaan: ”Roskaa sisään, roskaa ulos.” Kun rakennat datasta dashboardin ”nopeasti”, saatat johtaa tiimin harhaan.
Olen esimerkiksi nähnyt asiakkaiden tekevän A/B-testausta, jossa sessiot ja käyttäjät menivät sekaisin. Tämä pilasi testit valtavalla määrällä datapisteitä sen sijaan, että valikoivan ryhmittelyn avulla olisi selvitetty, oliko ominaisuus hyödyllinen vai ei.
Vaatimustenmukaisuuden ja sovelluksen elinkaaren mittarit ulottuvat usein useisiin tiimeihin, mikä on kokonaan oma optimointialueensa. Tarkastelemme näitä yleensä migraation jokaisessa vaiheessa esisuunnittelusta kestävyyteen.
Älä mittaa migraation onnistumista perinteisillä ohjelmistokehityksen elinkaaren mittareilla. Ne ovat harhaanjohtavia niin kauan kuin kattavuus ei ole riittävä. Käytä käyttöönottoa mittaavia mittareita.
Jotkut asiakkaistamme esimerkiksi ajattelivat pärjäävänsä hyvin DevOps-työkalujen osalta, mutta kun aloimme tutkia heidän DevOpsin käyttöään, heidän työkaluketjussaan oli käytössä vain versionhallinta. He siis tekivät DevOpsia vain hyvin rajallisesti ja keskittyivät vääriin asioihin kehittääkseen työkalujaan. Heidän mittarinsa kertoivat, että kaikki meni hyvin: työkalua käytettiin. Se oli teknisesti totta, mutta mittareiden pitäisi tukea tiimiä ja työskentelytapoja työkalussa, ei mitata tuotteen käyttöä.
Muutama loppusana
Tämän kirjoituksen työstäminen on ollut hauska kokemus: olen yrittänyt tiivistää aina yhtä vaikeasti tavoitettavan unelmien migraation. Tässä vielä muutama viimeinen neuvo.
Se ei välttämättä ole kaunista
Olen muutaman kerran onnistunut tekemään loistavia migraatioita, mutta ne ovat mielestäni hyvin harvinaisia. Yleensä niistä tulee hyvin sotkuisia, vaikka olenkin kerännyt viimeisten kymmenen vuoden aikana paljon tietoa DevOps-työkalujen ja pilven migraatioista. Joka kerta vaatimustenhallintaprosessin takana odottaa yllätys, jota korjaat yksin lauantaiyönä kello yhden aikaan tietäen, että testaus alkaa seuraavana aamuna. Jos kaikki ei ole valmista kello kymmeneen mennessä, koko migraatio siirtyy, ja joudut käymään läpi viimeisten 36 tunnin helvetin uudelleen. Siksi jatkat eteenpäin toivoen, että saat ongelman ratkaistua.
Älä pelkää epäonnistumista
Joskus onnistut, useammin epäonnistut. Älä pelkää epäonnistumista migraation aikana. Opi siitä, valmistaudu seuraavalla kerralla paremmin ja pyri välttämään yli 40 tuntia kestäviä migraatiopäiviä. Ne eivät ole terveellisiä eivätkä todellakaan tuottavia. Sopikaa työparin kanssa hyvästä työnjaosta ja tiedonsiirrosta ja pyrkikää siihen, että tiimillä on virkeä mieli.
Esimerkki onnistuneesta migraatiosta
Lopuksi haluan kertoa migraatiosta, joka sujui hyvin.
Menimme tapaamiseen, ja asiakas kertoi siirtyvänsä uuteen ratkaisuun seuraavan kuukauden aikana. Migraation oli onnistuttava, sillä vanha palveluntarjoaja lopettaisi ohjelmiston tuen puolentoista kuukauden kuluttua. Laadimme suunnitelman tuotteelle, jonka tunnemme hyvin, valmistelimme ympäristöt ja datamigraatiot sekä varmistimme, että kaikki oli valmista. Teimme lukuisia testimigraatioita ja tarkistimme, että kaikki sujui hyvin.
Tuotantoonottopäivänä aloitimme migraation, ja DNS siirrettiin sovitusti. DNS:ssä oli kuitenkin huomaamatta asetettu TTL-arvoksi yksi tunti, minkä vuoksi migraatio kesti puolitoista tuntia. Muita ongelmia ei ollut lainkaan, ja pääsimme tuotantoon suunnitellusti. Kaikesta kokemuksesta ja koulutuksesta huolimatta yksi huomaamatta jäänyt asia voi kolminkertaistaa tällaisen projektin keston. Migraatio sujui hyvin, ja olimme tyytyväisiä päästyämme tuotantoon.
Muista vain: yritä nauttia stressaavasta matkasta ja juhlia onnistumista. Nyt suuntaan oluelle juhlistamaan tämän datan migraatiota päästäni paperille.
- DevOps
- Eficode ROOT
Subscribe to our newsletter
Related blogs
