Praktisk GitLab-workflow for små team som vil få ting inn i produksjon uten drama

Mange små utviklingsteam ender opp med kaotiske GitLab-miljøer: tilfeldige brancher, manuelle deployer og MR-er som aldri blir godkjent. Det føles tungt, selv om GitLab egentlig kan gjøre mye av jobben for deg.

Her får du en konkret, jordnær workflow for GitLab som passer små team. Målet er å gi forutsigbarhet fra idé til produksjon, uten store prosessrammeverk eller avanserte enterprise-oppsett.

Grunnidéen: én hovedlinje og korte feature-brancher

Det viktigste valget er hvordan dere organiserer brancher. For små team er en enkel modell ofte best: én stabil hovedlinje, og korte feature-brancher som lever kort tid.

I GitLab betyr dette som regel at dere brukermainsom hovedbranch, og at alt nytt arbeid skjer i egne brancher som kobles til en merge request (MR) før de går inn i main.

Forslag til enkel branch-struktur

En struktur som fungerer for mange små team er:

• main: Alltid deploy-klar, det som ligger her kan i prinsippet gå til produksjon.
• feature/<beskrivelse>: For ny funksjonalitet eller forbedringer.
• fix/<beskrivelse>: For feilrettinger som ikke haster ekstremt.
• hotfix/<beskrivelse>: For akutte feil som må ut raskt.

Poenget er ikke navnestrukturen i seg selv, men at alle ser umiddelbart hva en branch er ment å gjøre, og hvor lenge den skal leve.

Lag en enkel mal for merge requests

GitLab støtter MR-maler som kan lagres i repoet. En god mal sparer tid og hindrer misforståelser. Målet er å tvinge frem nok info til at kollegaen din kan forstå endringen uten å lese all koden.

En kort og nyttig MR-mal kan inneholde:

• Beskrivelse: Hva er gjort, på 2–3 setninger.
• Motivasjon: Hvilket problem eller oppgave løses.
• Testet: Hvordan du har testet, for eksempel en liste med kommandoer eller sider du har sjekket.
• Risiko: Mulige bieffekter eller områder som bør få ekstra oppmerksomhet.

Slik kan en typisk arbeidsflyt se ut i praksis

Nedenfor er et konkret forløp fra oppgave til kode i main. Denne rytmen kan brukes enten dere jobber med GitLab Issues, et annet verktøy eller bare en delt oppgaveliste.

1. Lag eller ta en oppgave i tavlen dere bruker.
2. Opprett branch lokalt:git checkout -b feature/login-improvement.
3. Gjør endringene med hyppige commits, gjerne små og beskrivende.
4. Kjør tester og sørg for at alt er grønt lokalt.
5. Push branch til GitLab:git push -u origin feature/login-improvement.
6. Opprett MR i GitLab, knytt den til oppgaven og fyll ut MR-malen.
7. Få minst én kollega til å reviewe og godkjenne.
8. La GitLab CI kjøre automatiske tester før merge.
9. Merge til main når både review og CI er grønt.

Når dette mønsteret sitter, blir det mye enklere å se hvor ting stopper opp: på review, i testene eller i selve koden.

Bruk GitLab CI til å automatisere det kjedelige

Fordelen med GitLab er at testene kan kobles direkte til MR-ene. En enkel start er å ha én pipeline som kjører ved hver push til en branch og ved hver MR mot main.

En typisk enkel.gitlab-ci.ymlkan for eksempel ha steg for linting, enhetstester og eventuelt enkel bygging, slik at de vanligste feilene fanges før noen rekker å trykke merge.

Code review som ikke stopper alt opp

Code review kan fort bli en flaskehals hvis MR-er er for store eller for uklare. Nøkkelen for små team er å holde MR-er små nok til å lese på 10–15 minutter, og å fokusere på det viktigste.

Noen praktiske avtaler som ofte fungerer bra:

• MR-er over en viss størrelse krever ekstra begrunnelse, eller deles opp.
• Anmelder kommenterer på struktur, lesbarhet og risiko, ikke bare små detaljer.
• Den som lager MR tar ansvar for å svare kjapt på kommentarer og rydde opp.

Distribusjon: fra main til miljøene deres

Når main alltid er i god stand, kan dere koble den til deploy-pipelines i GitLab. Det kan være så enkelt som at hver merge til main utløser en deploy til et staging-miljø, mens produksjon krever et manuelt godkjenningssteg i GitLab.

For små team er det ofte nok med to miljøer i GitLab:stagingfor å verifisere funksjonalitet, ogproductionfor faktiske brukere. Hver pipeline kan markere miljøstatus direkte i GitLab, slik at alle ser hvor endringen befinner seg.

Håndtering av hotfixer uten å ødelegge flyten

Noen ganger må noe ut raskt, og den planlagte flyten ryker. Det viktigste er å ha en klar og enkel rutine for dette på forhånd, i stedet for å improvisere hver gang.

En mulig rutine kan være:

• Branch:hotfix/<beskrivelse>fra main.
• Kort MR med tydelig forklaring på feilen og løsningen.
• Direkte deploy til produksjon etter merge, men likevel via CI.
• Eventuell backport til andre brancher hvis dere har flere aktive linjer.

Vanlige feil i GitLab-workflow og hvordan unngå dem

Noen typiske problemer går igjen uansett teknologi, og GitLab er ikke noe unntak. Det gjelder særlig utydelige MR-er, manglende kobling til oppgaver og at CI ignoreres når det haster.

En kort huskeliste som kan hjelpe:

• Alltid MR: Unngå direkte push til main, også når det haster.
• Alltid kobling: Knytt MR-er til tasks eller issues, så historikken henger sammen.
• Alltid CI: Ikke merge hvis pipelinen er rød, avklar og fiks først.

Start smått og forbedre underveis

Du trenger ikke et perfekt opplegg fra dag én. Det viktigste er at teamet har en felles forventning til hvordan kode går fra lokal maskin til produksjon, og at GitLab brukes til å støtte det, ikke komplisere det.

Begynn med enkel branch-struktur, en lett MR-mal og grunnleggende CI. Etter noen uker vil det være tydelig hvilke steg som bør strammes inn eller forenkles, og da kan workflowen finjusteres sammen med teamet.