Migraatio ja transformaatio: kaksi kärpästä yhdellä iskulla

Hiiristä ja migraatioista

Transformaatiot ovat vieläkin riskialttiimpia hankkeita, sillä ne kohtaavat muutosvastarintaa. Kuka siis järjissään toteuttaisi migraation ja transformaation samanaikaisesti?

Itse asiassa me Eficodella suosittelemme aina ottamaan rohkean askeleen ja hyödyntämään jokaisen migraation mahdollisuutena toteuttaa muutoksia: päivittää parempiin työkaluihin, parantaa prosesseja, vahvistaa tietoturvaa ja niin edelleen. Jokainen migraatio, johon ei sisälly edes transformaation elementtiä, on menetetty mahdollisuus parantaa liiketoimintasi toimintatapoja.

Seuraavat asiat voi lähes aina tehdä paremmin migraation yhteydessä:

• Automaatio: Suuren organisaation prosesseissa automaatiota on harvoin liikaa.

• Tietoturva: Jatkuvasti muuttuvassa kyberturvallisuusympäristössä tietoturvan taso tuskin voi koskaan olla liian hyvä.

• Prosessien optimointi: Työnkulkujen pullonkaulojen ja päällekkäisyyksien tunnistaminen sekä niiden sujuvoittaminen nopeampaa toimitusta ja parempaa yhteistyötä varten.

• Kulttuurimuutos: Uusien työskentelytapojen kannustaminen, innovoinnin edistäminen sekä tiimien ohjaaminen ottamaan uudet käytännöt ja työkalut tehokkaasti käyttöön.

Kuulostaako houkuttelevalta? Se on varmasti kalliimpaa, eikö? Kyllä ja ei. Muutoksen suunnittelu vaatii aina työtä ja resursseja, mutta se on myös investointi tulevaan tuottavuuden kasvuun. Migraation ja transformaation yhdistäminen ei kuitenkaan välttämättä lisää hankkeen monimutkaisuutta. Nykytilanteen huolellisella arvioinnilla, tavoitetilan selkeällä ymmärryksellä, oikealla resursoinnilla ja hyvällä ennakkosuunnittelulla migraatiotransformaatio voi auttaa parantamaan organisaatiosi toimintaa ja suorituskykyä.

Eräässä viimeaikaisessa migraatiotransformaatiossamme autoimme asiakasta saavuttamaan korkeamman kypsyystason Platform Engineeringissä, kehittämään identiteetin- ja pääsynhallintajärjestelmiään sekä toteuttamaan alustaan integroidut itsepalvelumigraatiotyökalut – samalla kun asiakkaan kriittisten järjestelmien käyttökatkot pidettiin mahdollisimman lyhyinä. Haluamme jakaa tämän tarinan kaikkien asiakkaidemme kanssa.

Migraatio osana Platform Engineeringiä

Kyseisellä asiakkaalla oli vanhentunut Bitbucket Server, joka piti migroida mahdollisimman pian GitHub Enterprise Cloudiin Enterprise Managed Userin kanssa.

Bitbucketissa ei ollut keskitettyä pääsynhallintaa eikä hallintamallia. Lisäksi kaikki tuotteen hallintaan ja käyttäjähallintaan liittyvä työ tehtiin manuaalisesti. Kyseessä oli tyypillinen sotku: vuosia laiminlyöty työkalu oli ajautunut tilanteeseen, jossa se ei ollut vain kehitystyön pullonkaula, vaan aiheutti myös compliance- ja tietoturvariskejä.

Asiakkaan tavoitetilana oli siirtyä GitHubiin ja samalla tehdä perustavanlaatuisia muutoksia tapaan, jolla koodikanta jäsennetään ja käyttäjiä hallitaan:

• Migraatio rappeutuvasta Bitbucketista GitHub Enterprise Cloudiin Enterprise Managed Usersin kanssa.

• C4-ohjelmistoarkkitehtuurikehyksen käyttöönotto.

• Zero Trust -periaatteisiin perustuvan IAM-mallin toteuttaminen. Malliin kuuluvat esimerkiksi Role Based Access Control, Just Enough Access sekä identiteetin elinkaaren täysi hallinta.

Yli 4 000 repositorion ja 58 kehittäjätiimin ympäristössä muutoksia on paljon toteutettavaksi kerralla. Vuosi työn aloittamisen jälkeen asiakas on kuitenkin saavuttanut tavoitetilan – ja tehnyt sen sujuvasti ilman merkittäviä ongelmia.

Itsepalvelumigraatio

Migraatio- ja transformaatiohankkeen monimutkaisuuden vuoksi tavoitteenamme oli mahdollisimman pitkälle viety standardointi ja automaatio. Päätimme hyödyntää asiakkaan olemassa olevia työkaluja, eli Backstagea, Platform APIa, Entra ID:tä ja MyAccessia. Nykyiset migraatiotyökalut integroitiin asiakkaan hallinnoimaan työkalukokonaisuuteen, jotta asiakkaan Internal Developer Platformiin, Backstageen, voitiin rakentaa itsepalvelumigraatiokokemus. Loppukäyttäjät syöttivät tarvittavat tiedot Backstagen käyttöliittymään käynnistääkseen päästä päähän -putken, joka hallitsi repositoriomigraation koko elinkaarta. Automatisoitu migraatioputki hoiti kaiken alusta loppuun:

• Git-repositorioiden ja niihin liittyvien metatietojen, kuten issueiden, PR:ien ja liitteiden, migrointi Bitbucketista GitHubiin C4-mallin mukaisesti.
  Kaikkien lähderepositorion branchien asettaminen vain luku -tilaan migraation ajaksi.
  Ristiriitojen ratkaisu lennossa.
  Large File Storage -sisällön migrointi.
  Käyttöoikeuksien poistaminen kaikilta käyttäjiltä ja ryhmiltä Bitbucket-ympäristössä, jolloin lähdeympäristö lukittiin tehokkaasti.
  Repositorion uudelleennimeäminen lisäämällä repositorion nimeen etuliite ennen sen siirtämistä Archival-projektiin (esimerkiksi PRJ.<repo_name>).

• Repositoriodatan eheyden validointi migraation jälkeen vertaamalla jokaisen branchin viimeisimmän commitin hash-arvoa lähde- ja kohderepositorion välillä.

• RBAC-mallin mukaisen GitHub-tiimien ja Entra ID -ryhmien luominen ja provisionointi GitHub-ympäristöön, jotta käyttäjät voitiin migroida sujuvasti uuteen ympäristöön.

• Koko prosessin lokitus Grafanaan.

• Oikeiden asetusten lisääminen GitHub-repositorioon osana migraation jälkeistä prosessia.

• Aseta kaikki lähderepositorion haarat vain luku -tilaan migraation ajaksi.

• Konfliktien ratkaisu lennossa.

• Suurten tiedostojen tallennussisällön migraatio.

• Kaikkien käyttäjien ja ryhmien käyttöoikeudet poistettiin Bitbucket-ympäristöstä (lähdeympäristö lukittiin käytännössä kokonaan).

• Nimeä repositorio uudelleen lisäämällä repolle etuliite ennen sen siirtämistä arkistointiprojektiin (esim. PRJ.<repo_name>).

Ennen tuotantomigraatioita koko migraatioprosessi testattiin ja dokumentoitiin perusteellisesti, jotta migraatiot voitiin toteuttaa luottavaisesti laajassa mittakaavassa. Migraation aikana tarjottiin tukea mahdollisten ongelmien ratkaisemiseksi varotoimena. Prosessin aikana ei ilmennyt merkittäviä virheitä, vaan havaittiin vain muutamia ongelmia, jotka kaikki korjattiin 24 tunnin kuluessa.

Tuloksena asiakasdata siirrettiin vanhasta työkalusta uuteen GitHub Enterprise Cloudiin, ja kaikki toteutettiin käytännössä lähes ilman käyttökatkoja tai häiriöitä.

Samalla toteutettiin kulttuurimuutos. Tiukat käyttöoikeuksien hallintatoimet rajasivat esimerkiksi repositorioiden luomisen palvelutileille (SA) ja organisaation ylläpitäjille, mikä loi Zero Trust -periaatteisiin perustuvan keskitetyn hallintamallin.

Käyttäjien on nyt tehtävä MyAccessin kautta pyyntö kaikkiin repositorioihin liittyviin toimiin. Repositorioiden poistamista rajoitettiin, ja se on mahdollista vain virallisen pyyntö- ja arviointiprosessin kautta. Myös repositorioiden käyttöoikeuksia on pyydettävä, jotta käyttöoikeuksia voidaan hallita tehokkaasti. Kaikki on automatisoitu, keskitetty, monitoroitu ja lokitettu.

Migraation jälkeen

Projekti toteutti sen, mitä luvattiin: asiakasdata siirrettiin Bitbucketista GitHubiin ajallaan ja ilman häiriöitä liiketoiminnalle. Lisäksi toteutettiin laaja joukko muita yhtä merkittäviä muutoksia.

Parempi tietoturva- ja compliance-tilanne

Identiteetin- ja käyttöoikeuksien hallinnan prosessit uudistettiin kokonaan. Ne perustuvat nyt Zero Trust -periaatteisiin. Yhdessä IAM-prosessien automatisoinnin kanssa ne parantavat organisaation tietoturvaa ja auttavat säilyttämään vaatimustenmukaisuuden esimerkiksi ISO 270001- ja NIS2-viitekehysten osalta.

IT-prosessien automatisointi

Olennainen osa migraatioprosessia oli rakentaa automaatio käyttäjien käyttöoikeuksien käyttöönottoon ja kehitystyössä tarvittavien resurssien määrittämiseen.

Uudet automatisoidut prosessit lisäävät johdonmukaisuutta, tehokkuutta ja tietoturvaa sekä vahvistavat DevSecOps-standardeja. Samalla DevSecOps-tiimi voi keskittyä arvokkaampiin tehtäviin toistuvien rutiinien, kuten repositorioiden luomisen ja käyttäjähallintapyyntöjen, sijaan.

Organisaatiomuutos

Migraatiota hyödynnettiin ohjelmistoarkkitehtuurin toimintamallin uudistamiseen. Se paransi kehityskäytäntöjä ja teki laajasta koodikokonaisuudesta helpommin hallittavan ja ymmärrettävän.

Platform Engineeringin vahvempi hyödyntäminen

Migraatioprosessi rakennettiin olemassa olevien kehittäjäalustan työkalujen (Backstage, Platform API) varaan, ja niitä hyödynnettiin täysimääräisesti. Tämän seurauksena organisaation Platform Engineering -kypsyys nousi uudelle tasolle.