Releases, tags og GitHub Actions

Hvorfor arbejder vi med releases?

På GitHub er det standard at arbejde med releases. En release markerer et tydeligt punkt i projektet, hvor noget kan vises frem, testes eller overleveres.

• 1
  Et tydeligt milepæl — En release markerer et klart punkt i projektet — noget konkret I kan pege på og sige: "Det her er klar nu."
• 2
  Vis frem, test, overlever — Releases bruges til at vise produktet frem for kunden, lade dem teste og overlevere det, I har bygget i sprinten.
• 3
  Grundlag for feedback — Når kunden ved præcis hvilken version de kigger på, bliver feedback konkret og handlingsbar — ikke "det virker ikke" uden kontekst.
• 4
  Professionel standard — På GitHub er releases standard i professionelle teams. Det signalerer struktur, sporbarhed og at I tager jeres leverance alvorligt.

Sådan gør vi det

Nogle faste rammer gør det nemmere for jer og jeres kunde at have en fælles forståelse.

• Release ved sprint-slut

  En release kobles typisk til sprint-slut og fungerer som det punkt, hvor I samler op og får feedback — præcis som i rigtige udviklingsteams.

• En release om ugen

  Som udgangspunkt laver I en release pr. uge. Det giver en fast rytme og sikrer, at kunden løbende ser fremgang.

• Patches undervejs

  I må gerne lave patch-releases (v0.2.1, v0.2.2) mellem sprint-slut, hvis kritiske fejl skal rettes hurtigt.

• Den vigtige regel

  Ingen commits på main uden en release til jeres kunde. Main er jeres leverance-klar kode — det der står der, skal kunne vises frem.

Semantisk versionering

Vi bruger Semantic Versioning — formatet er vMAJOR.MINOR.PATCH. Første release er typisk v0.1.0, fordi systemet stadig er under aktiv udvikling.

Se det i praksis

Vil du have en god struktur, kan du kigge på open-source projekter og se hvordan de gør. Her er to konkrete eksempler:

Hvad sker der bag kulisserne?

Bag hver release ligger Git-tags, GitHub Releases og ofte automatiseret CI/CD. Her er de fire byggesten:

• 1
  Release — En release er en markeret version af din kode — typisk navngivet med semantisk versionering som v1.0.0.
• 2
  Tag — Et Git-tag er et fast referencepunkt til et bestemt commit. Tags bruges til at markere releases.
• 3
  GitHub Release — En GitHub Release tilføjer release-noter, downloadbare filer og synlighed på repository-siden.
• 4
  GitHub Actions — Med Actions kan du automatisere build, test og publicering, når et tag pushes til GitHub.

Release-flow — visuelt

Fra commit på main til tag, release og Actions — klik på hvert trin.

Kommandoer i flowet

De vigtigste trin og kommandoer bag release-processen.

Trin-for-trin guide

Følg disse trin for at lave din release med tag og GitHub Actions.

# Tjek at du er på main og alt er committed
git checkout main
git pull origin main
git status

Eksempel: GitHub Actions workflow

Dette workflow trigges automatisk når du pusher et tag der matcher v*. Gem det som .github/workflows/release.yml i dit repository.

name: Release

on:
  push:
    tags:
      - 'v*'

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: npm ci && npm run build
      - name: Create GitHub Release
        uses: softprops/action-gh-release@v2
        with:
          generate_release_notes: true

Test din viden

Svar på spørgsmålene for at tjekke om du har styr på releases, semver, tags og Actions.