Migreringsguide · Fra GitHub
Migrer fra GitHub til SIAX Git og CI
GitHub er ikke et dårligt værktøj, og det er sjældent grunden til, at nogen flytter. Grundene er som regel tre: licensomkostningen pr. udvikler, der vokser med teamet, CI-minutter der er svære at forudsige, og at både koden og byggekæden ligger under amerikansk jurisdiktion. For virksomheder, der sælger til den offentlige sektor eller regulerede kunder, er det sidste argument ofte det, der afgør det.
Vores Git og CI er selvhostet Gitea med Actions-kompatible runnere, alt sammen i EU. Git-protokollen er den samme, så kloner, remotes og værktøjer fungerer uændret, og workflow-syntaksen er i alt væsentligt den samme som GitHub Actions. Prisen er 199 kr/md. for ti brugere, mod licens pr. udvikler plus variabel CI-omkostning.
Den ærlige advarsel: Actions-kompatibiliteten er god, men ikke identisk. Workflow-filerne kan som regel kopieres direkte, men enkelte marketplace-actions skal udskiftes, og dele af GitHubs økosystem — Codespaces, Advanced Security, Pages, OIDC-federation mod cloududbydere — har ingen pendant. Denne guide lægger tiden der, hvor arbejdet reelt ligger: i pipelinen, ikke i koden.
Tidsforbrug
En halv dag for et repo med en simpel pipeline. For 20-30 repos med aktive workflows: regn med to til tre arbejdsdage, hvor størstedelen går med at gentteste workflows — ikke med at flytte kode.
Nedetid
Ingen for koden. Git er distribueret, og alle har fuldstændige kloner, så selve repoflytningen mærkes ikke. CI har til gengæld et hul: under omskrivningen er der en periode, hvor bygget kun er verificeret på ét af systemerne. Kør begge parallelt, til resultaterne stemmer overens, før I gør vores CI obligatorisk.
Sådan gør du
- 1
Kortlæg repos, workflows og integrationer
List alle repos med seneste commit, størrelse og om de bruger LFS. Gennemgå hvert aktive workflow, og notér hvilke actions det bruger, hvilke hemmeligheder det læser, og hvad det deployer til. Notér også alt, der ligger uden for Git: GitHub Apps, webhooks, branch-beskyttelse, code owners og obligatoriske statustjek. Den liste er jeres reelle kravspec — ikke repolisten.
- 2
Sæt organisation, brugere og rettigheder op
Opret organisationen hos os, og opret teams med de samme rettighedsniveauer som i GitHub. Kobl login til jeres eksisterende identitetsudbyder via OIDC, hvis I har en — ellers lokale konti med tvunget to-faktor. Sæt branch-beskyttelsen op med det samme — det er let at udskyde, og det mærkes først, når nogen pusher til main.
- 3
Spejl repos, og flyt sagshistorikken
Migreringsværktøjet henter repo, tags, releases, wiki, issues og pull requests via GitHub-API'et med en personlig access token. Kør en testmigrering af et mellemstort repo først, og gennemgå resultatet, før I tager resten. LFS-objekter og containerimages i ghcr.io flyttes separat og følger ikke med i samme omgang.
- 4
Flyt hemmeligheder — og rotér dem samtidig
Hemmeligheder kan ikke læses ud af GitHub, så de skal sættes op på ny under alle omstændigheder. Udnyt det: rotér hver nøgle i forbindelse med flytningen i stedet for at indsætte de samme værdier igen. Læg dem på organisationsniveau, hvor flere repos deler dem, og dokumentér hvilken pipeline der har brug for hvilken.
- 5
Skriv workflows om, og udskift de actions, der ikke holder
Syntaksen i .gitea/workflows er i alt væsentligt den samme som GitHub Actions, så filerne kan som regel kopieres direkte. Test derefter hvert workflow: almindelige actions som checkout, setup-node og cache fungerer normalt, mens dem, der kalder GitHubs eget API, bruger OIDC-federation eller forudsætter GitHubs runner-image, ikke gør. Lås versioner eksplicit, og erstat det, der fejler, med rene shell-trin. Regn med, at dette trin tager mest tid af alle.
- 6
Kør begge systemer parallelt, til resultaterne stemmer
Behold GitHub som spejl, og push til begge remotes i en periode. Sammenlign buildlog mod buildlog på samme commit — forskelle skyldes som regel forinstallerede værktøjer i runner-imaget, ikke jeres kode. Først når ti til femten kørsler i træk giver samme resultat, er det rimeligt at gøre vores CI til obligatorisk statustjek.
- 7
Peg deploy-mål og webhooks om, og arkivér derefter GitHub
Opdatér deploy-nøgler, containerregistre og alle webhooks, der peger på github.com. Deployer pipelinen til vores App Hosting (fra 99 kr/md.), er en deploy-nøgle og en webhook nok. Sæt GitHub-repoerne i arkiveret, skrivebeskyttet tilstand i stedet for at slette dem — ellers holder gamle permalinks i dokumentation og sager op med at virke. Behold dem i mindst et kvartal.
Hvad der faktisk er besværligt
- Marketplace-actions fungerer ikke altid uændret. Det, der bare kører kommandoer, går fint; det, der kalder GitHubs REST- eller GraphQL-API, bruger OIDC-federation mod AWS eller GCP, eller stoler på GitHubs runner-image, gør ikke. Test hver action, lås versioner, og regn med at erstatte nogle med shell-trin.
- Runner-imaget er ikke GitHubs ubuntu-latest. Pipelines, der antager, at et værktøj allerede er installeret, fejler — ofte med en kryptisk fejl langt inde i bygget. Installér afhængigheder eksplicit i workflowet i stedet for at stole på imaget.
- OIDC-federation mod cloududbydere forsvinder. Workflows, der henter midlertidige AWS- eller GCP-credentials via GitHubs identitetsudbyder, skal gå over til langlivede nøgler eller en anden mekanisme. Det er en sikkerhedsforringelse, der skal håndteres bevidst — ikke opdages i bagklogskabens lys.
- Dele af GitHub har ingen pendant: Codespaces, Advanced Security og kodescanning, Pages, Discussions og org-dækkende rulesets. Er noget af det forretningskritisk, er svaret ikke at flytte alt, men at flytte det, der kan lade sig gøre, og betale for resten.
- Sagshistorikken følger med som tekst, men reviewtråde i pull requests, historikken for statustjek og permalinks til github.com gør det ikke fuldt ud. Links i gammel dokumentation peger stadig derhen — derfor skal GitHub-repoerne arkiveres, ikke slettes.
Omkostningseksempel
Et team på ti udviklere på GitHub Team ligger på cirka 40 USD om måneden i licenser, altså groft 450 kr, plus det, CI-minutterne koster ud over den inkluderede pulje. For et aktivt monorepo med mange parallelle builds bliver CI-posten ofte større end licenserne. Priser og inkluderede mængder ændrer sig løbende — tjek den aktuelle prisliste. Det tilsvarende hos os: Git og CI 199 kr/md. for ti brugere. Har I brug for tunge parallelle builds, dimensionerer vi en dedikeret runner på en dedikeret server fra 890 kr/md., hvilket stadig er forudsigeligt i stedet for variabelt.
Ofte stillede spørgsmål
- Fungerer vores GitHub Actions-workflows uændret?
- Filerne kan som regel kopieres uden ændring — syntaksen er den samme. Actions er en anden sag: de mest almindelige fungerer, men dem, der taler med GitHubs API eller bruger OIDC-federation, gør ikke. Regn med at teste og justere hvert workflow — ikke med at flytte dem blindt over.
- Følger issues og pull requests med?
- Ja, migreringsværktøjet henter issues, pull requests, releases, tags og wiki via GitHub-API'et. Reviewtråde og historikken for statustjek bliver ikke identiske. Kør en testmigrering på et repo, og se på resultatet, før I beslutter jer for hele flytningen.
- Kan vi beholde GitHub parallelt?
- Ja, og vi anbefaler det under overgangen. Git er distribueret, så at pushe til to remotes er én linje i konfigurationen. Mange beholder GitHub som skrivebeskyttet spejl permanent for offentlige repos.
- Hvad sker der med containerimages i ghcr.io?
- De flyttes separat. Pakkeregistret hos os taler samme OCI-protokol, så det handler om at tagge om og pushe — plus at opdatere alle pull-referencer i Kubernetes-manifester, compose-filer og deploy-scripts. Glem ikke hemmelighederne til image-hentning.
- Har I ISO 27001 eller SOC 2?
- Nej. Vi har hverken ISO 27001, SOC 2 eller PCI-DSS. Det, vi har, er GDPR-compliance med al data i EU, open source hele vejen ned, så I kan gennemgå, hvad der kører, og aftaler der giver jer mulighed for at hente data ud, når I vil. Har jeres udbud et certificeringskrav, skal I vide det, før projektet starter.
- Hvordan kommer vi ud igen, hvis det ikke fungerer?
- Klon repoerne — de indeholder hele historikken. Issues og pull requests eksporteres via API'et, og workflow-filerne ligger allerede i repoet. Samme vej ud som ind, hvilket er hele pointen med åbne formater.