Migraatio-opas · GitHub:sta
Siirry GitHubista SIAXin Git- ja CI-palveluun
GitHub ei ole huono työkalu, eikä se yleensä ole syy siihen että joku siirtyy pois. Syitä on tavallisesti kolme: kehittäjäkohtainen lisenssikustannus joka kasvaa tiimin mukana, CI-minuutit joita on vaikea ennakoida, ja se että sekä koodi että build-ketju sijaitsevat Yhdysvaltain lainkäyttövallan alla. Yrityksille jotka myyvät julkiselle sektorille tai säännellyille asiakkaille viimeinen argumentti on usein se joka ratkaisee.
Meidän Git- ja CI-palvelumme on itseisännöity Gitea Actions-yhteensopivilla runnereilla, kaikki EU:ssa. Git-protokolla on sama, joten kloonit, remotet ja työkalut toimivat muuttumattomana, ja workflow-syntaksi vastaa pääosin GitHub Actionsia. Hinta on 199 kr/kk kymmenelle käyttäjälle, verrattuna kehittäjäkohtaiseen lisenssiin plus vaihtelevaan CI-kustannukseen.
Rehellinen varoitus: Actions-yhteensopivuus on hyvä muttei identtinen. Workflow-tiedostot voi useimmiten kopioida sellaisenaan, mutta yksittäiset marketplace-actionit pitää vaihtaa, ja osalle GitHubin ekosysteemistä — Codespaces, Advanced Security, Pages, OIDC-federointi pilvitoimittajiin — ei ole vastinetta. Tämä opas laittaa ajan sinne missä työ oikeasti on: pipelineen, ei koodiin.
Ajankäyttö
Puoli päivää repolle jossa on yksinkertainen pipeline. 20–30 repolle joilla on aktiivisia workfloweja: varautukaa kahdesta kolmeen työpäivään, josta suurin osa menee workflowien testaamiseen — ei koodin siirtämiseen.
Käyttökatko
Ei koodille. Git on hajautettu ja kaikilla on täydelliset kloonit, joten itse reposiirto ei näy mitenkään. CI:ssä sen sijaan on aukko: uudelleenkirjoituksen aikana on jakso jolloin build on varmennettu vain toisessa järjestelmässä. Ajakaa molempia rinnakkain kunnes tulokset täsmäävät ennen kuin teette CI:stämme pakollisen.
Näin teet sen
- 1
Kartoita repot, workflowt ja integraatiot
Listatkaa kaikki repot viimeisimmällä commitilla, koolla ja sillä käyttävätkö ne LFS:ää. Käykää läpi jokainen aktiivinen workflow ja kirjatkaa mitä actioneja se käyttää, mitä salaisuuksia se lukee ja mihin se deployaa. Kirjatkaa myös kaikki mikä on Gitin ulkopuolella: GitHub Apps, webhookit, branch-suojaus, koodin omistajat ja pakolliset statustarkistukset. Tämä lista on teidän todellinen vaatimusmäärittelynne — ei repolista.
- 2
Pystytä organisaatio, käyttäjät ja käyttöoikeudet
Luokaa organisaatio meillä ja lisätkää tiimit samoilla käyttöoikeustasoilla kuin GitHubissa. Yhdistäkää kirjautuminen olemassa olevaan identiteettitoimittajaanne OIDC:n kautta jos teillä on sellainen, muuten paikalliset tilit pakotetulla kaksivaiheisella tunnistautumisella. Asettakaa branch-suojaus heti — sen lykkääminen on helppoa ja huomataan vasta kun joku pushaa mainiin.
- 3
Peilaa repot ja siirrä issue-historia
Migraatiotyökalu hakee repon, tagit, julkaisut, wikin, issuet ja pull requestit GitHub-API:n kautta henkilökohtaisella access tokenilla. Ajakaa testimigraatio keskikokoiselle repolle ensin ja tarkastakaa tulos ennen kuin otatte loput. LFS-objektit ja containerimaget ghcr.io:ssa siirtyvät erikseen eivätkä tule mukana samassa ajossa.
- 4
Siirrä salaisuudet — ja kierrätä ne samalla
Salaisuuksia ei voi lukea ulos GitHubista, joten ne pitää joka tapauksessa asettaa uudelleen. Hyödyntäkää se: kierrättäkää jokainen avain siirron yhteydessä sen sijaan että liimaatte samat arvot. Laittakaa ne organisaatiotasolle siellä missä useampi repo jakaa ne, ja dokumentoikaa mikä pipeline tarvitsee mitäkin.
- 5
Kirjoita workflowt uudelleen ja vaihda actionit jotka eivät kanna
.gitea/workflows-syntaksi vastaa pääosin GitHub Actionsia, joten tiedostot voi useimmiten kopioida sellaisenaan. Testatkaa sitten jokainen workflow: tavalliset actionit kuten checkout, setup-node ja cache toimivat normaalisti, kun taas ne jotka kutsuvat GitHubin omaa API:a, käyttävät OIDC-federointia tai olettavat GitHubin runner-imagen, eivät toimi. Lukitkaa versiot eksplisiittisesti ja korvatkaa se mikä kaatuu puhtailla shell-askelilla. Varautukaa siihen että tämä vaihe vie eniten aikaa kaikista.
- 6
Aja molempia järjestelmiä rinnakkain kunnes tulokset täsmäävät
Pitäkää GitHub peilinä ja pushatkaa molempiin remoteihin jakson ajan. Vertailkaa build-lokia build-lokiin samalla commitilla — erot johtuvat yleensä runner-imagen esiasennetuista työkaluista, ei koodistanne. Vasta kun kymmenen–viisitoista peräkkäistä ajoa antaa saman tuloksen, on kohtuullista tehdä CI:stämme pakollinen statustarkistus.
- 7
Ohjaa deploy-kohteet ja webhookit uudelleen, arkistoi sitten GitHub
Päivittäkää deploy-avaimet, containerrekisteri ja kaikki webhookit jotka osoittavat github.comiin. Jos pipeline deployaa App Hostingiimme (alkaen 99 kr/kk), riittää deploy-avain ja webhook. Asettakaa GitHub-repot arkistoituun, kirjoitussuojattuun tilaan sen sijaan että poistaisitte ne — vanhat permalinkit dokumentaatiossa ja issueissa lakkaavat muuten toimimasta. Pitäkää ne vähintään vuosineljänneksen.
Mikä on todella hankalaa
- Marketplace-actionit eivät aina toimi muuttumattomana. Se mikä vain ajaa komentoja toimii hyvin; se mikä kutsuu GitHubin REST- tai GraphQL-API:a, käyttää OIDC-federointia AWS:ään tai GCP:hen, tai luottaa GitHubin runner-imageen, ei toimi. Testatkaa jokainen action, lukitkaa versiot ja varautukaa korvaamaan osa shell-askelilla.
- Runner-image ei ole GitHubin ubuntu-latest. Pipelinet jotka olettavat että työkalu on jo asennettu, kaatuvat, usein kryptisellä virheellä pitkällä buildin sisällä. Asentakaa riippuvuudet eksplisiittisesti workflowssa sen sijaan että luotatte imageen.
- OIDC-federointi pilvitoimittajiin katoaa. Workflowt jotka hakevat väliaikaisia AWS- tai GCP-credentialeja GitHubin identiteettitoimittajan kautta pitää siirtää pitkäikäisiin avaimiin tai muuhun mekanismiin. Se on tietoturvaheikennys jota pitää käsitellä tietoisesti, ei huomata jälkikäteen.
- Osalle GitHubia ei ole vastinetta: Codespaces, Advanced Security ja koodiskannaus, Pages, Discussions ja organisaatiotason rulesetit. Jos jokin niistä on liiketoimintakriittinen, vastaus ei ole siirtää kaikkea, vaan siirtää se mikä onnistuu ja maksaa lopusta.
- Issue-historia tulee mukana tekstinä, mutta pull requestien katselutraitit, statustarkistusten historia ja permalinkit github.comiin eivät tule täysin mukana. Linkit vanhassa dokumentaatiossa osoittavat edelleen sinne — siksi GitHub-repot pitää arkistoida, ei poistaa.
Kustannusesimerkki
Kymmenen kehittäjän tiimi GitHub Teamissa maksaa noin 40 USD kuukaudessa lisensseissä, eli karkeasti 450 kr, plus se mitä CI-minuutit maksavat sisältyvän potin ylitse. Aktiiviselle monorepolle jolla on paljon rinnakkaisia buildeja CI-erä on usein suurempi kuin lisenssit. Hinnat ja sisältyvät volyymit muuttuvat jatkuvasti — tarkistakaa ajantasainen hinnasto. Vastaava meillä: Git ja CI 199 kr/kk kymmenelle käyttäjälle. Jos tarvitsette raskaita rinnakkaisia buildeja, mitoitamme oman runnerin dedikoidulla palvelimella alkaen 890 kr/kk, mikä on silti ennakoitava vaihtelevan sijaan.
Usein kysytyt kysymykset
- Toimivatko GitHub Actions -workflowmme sellaisenaan?
- Tiedostot voi useimmiten kopioida ilman muutoksia — syntaksi on sama. Actionit ovat eri asia: yleisimmät toimivat, mutta ne jotka puhuvat GitHubin API:n kanssa tai käyttävät OIDC-federointia, eivät. Varautukaa testaamaan ja säätämään jokaista workflowta, älkää siirtämään niitä sokkona.
- Tulevatko issuet ja pull requestit mukana?
- Kyllä, migraatiotyökalu hakee issuet, pull requestit, julkaisut, tagit ja wikin GitHub-API:n kautta. Katselutraitit ja statustarkistusten historia eivät tule identtisinä. Ajakaa testimigraatio yhdelle repolle ja katsokaa tulosta ennen kuin päätätte koko siirrosta.
- Voimmeko säilyttää GitHubin rinnakkain?
- Kyllä, ja suosittelemme sitä siirtymän ajaksi. Git on hajautettu, joten pushaaminen kahteen remoteen on yksi rivi konfiguraatiossa. Moni säilyttää GitHubin kirjoitussuojattuna peilinä pysyvästi julkisille repoille.
- Mitä tapahtuu ghcr.io:n containerimageille?
- Ne siirtyvät erikseen. Pakettirekisterimme puhuu samaa OCI-protokollaa, joten kyse on uudelleentagauksesta ja pushaamisesta — sekä kaikkien pull-referenssien päivittämisestä Kubernetes-manifesteissa, compose-tiedostoissa ja deploy-skripteissä. Älkää unohtako imagen hakusalaisuuksia.
- Onko teillä ISO 27001 tai SOC 2?
- Ei. Meillä ei ole ISO 27001:tä, SOC 2:ta eikä PCI-DSS:ää. Meillä on GDPR-vaatimustenmukaisuus kaiken datan ollessa EU:ssa, avoin lähdekoodi aivan pohjalle asti niin että voitte tarkastaa mitä ajetaan, ja sopimukset jotka antavat teille datan ulosviennin milloin haluatte. Jos kilpailutuksessanne on sertifiointivaatimus, se pitää tietää ennen projektin aloitusta.
- Miten pääsemme pois jos tämä ei toimi?
- Klonatkaa repot — ne sisältävät koko historian. Issuet ja pull requestit viedään API:n kautta ja workflow-tiedostot ovat jo repossa. Sama tie ulos kuin sisään, mikä on avointen formaattien koko pointti.