GitHub Actions CI/CD: praktický příklad workflow

1. Co je GitHub Actions

GitHub Actions spouští automatizované úlohy jako reakci na události v repozitáři, jako je například push, schválení pull requestu nebo nový tag. Jednotlivé úlohy workflow jsou popsány v souboru YAML ve složce .github/workflows. Běží na tzv. runneru, což je virtuální stroj, který GitHub pro každou úlohu připraví a po dokončení jej zahodí.

CI (continuous integration, průběžná integrace) znamená, že se každá změna automaticky sestaví a otestuje. CD (continuous delivery nebo deployment, průběžné doručování či nasazování) hotové sestavení nasadí. Obojí lze realizovat v jednom nebo několika workflow v jednom repozitáři. Podrobný popis syntaxe najdete v dokumentaci GitHubu.

2. CI workflow: testy u každého pull requestu

CI workflow v GitHub Actions spustí instalaci závislostí, testy a build u každého pull requestu a u každého pushe do hlavní větve. Pull request s neprošlými testy pak GitHub označí červeně a v nastavení ochrany větve můžete úplně zakázat její sloučení. Příklad je pro aplikaci v Node.js, u jiného jazyka vyměníte setup-node a příkazy npm.

name: CI

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v5
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm test
      - run: npm run build

3. CD workflow: nasazení po tagu verze

V tomto režimu se nasazovací workflow spustí v momentě, kdy do repozitáře pošlete tag verze, například v1.4.2. Workflow si z tagu vezme číslo verze bez předpony "v" a najde předchozí tag, který slouží pro vymezení proběhlých změn. To, jak tagy vznikají, závisí na strategii větvení a také na zvoleném schématu verzí.

Uvedený job deploy běží v prostředí "production". V nastavení repozitáře (Settings → Environments) k němu můžete přidat schvalovatele a uložit přístupové údaje k serveru jako "secrets" prostředí. Skript deploy.sh zastupuje váš skutečný způsob nasazení: rsync na server, push Docker image nebo příkaz hostingu.

name: Release

on:
  push:
    tags:
      - "v*"

permissions:
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v5
        with:
          fetch-depth: 0

      - name: Resolve release metadata
        id: release
        run: |
          echo "version=${GITHUB_REF_NAME#v}" >> "$GITHUB_OUTPUT"
          previous_tag=$(git describe --tags --match 'v*' --abbrev=0 HEAD^ 2>/dev/null || true)
          echo "previous-tag=$previous_tag" >> "$GITHUB_OUTPUT"

      - uses: actions/setup-node@v5
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm test
      - run: npm run build
        env:
          VITE_APP_VERSION: ${{ steps.release.outputs.version }}

      - name: Deploy
        run: ./scripts/deploy.sh
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

4. Zápis verze a nasazení do AboutTheApp

Verzi a nasazení do AboutTheApp zapíše akce Report release to AboutTheApp (abouttheapp/sync) jako poslední krok nasazovacího workflow. Uloží číslo verze, její poznámky k vydání a instalaci u zákazníka v konkrétním prostředí.

Bez tohoto kroku zůstane informace o nasazení jen v logu běhu workflow a v commitech, kam se podpora ani zákazník nedostanou.

1. 1

   Založte produkt a zákazníka

   V dashboardu AboutTheApp založte produkt a zákazníka s aliasem. Pokud nechcete evidovat nasazení u zákazníků nebo na různých prostředích, stačí založit jen produkt.

2. 2

   Vygenerujte si klíč pro CI/CD

   V uživatelském menu otevřete Účet → CI/CD a klikněte na Vygenerovat klíč. Klíč uvidíte jen jednou a platí pro všechny produkty v účtu. Vygenerování nového klíče ten starý zneplatní.

3. 3

   Uložte klíč jako secret

   Na GitHubu v repozitáři otevřete Settings → Secrets and variables → Actions a klíč uložte pod názvem ABOUTTHEAPP_TOKEN.

4. 4

   Přidejte krok na konec nasazení

   Krok níže vložte na konec jobu deploy. Spustí se jen tehdy, když předchozí kroky včetně nasazení skončily úspěšně.

      - name: Report release to AboutTheApp
        uses: abouttheapp/sync@v1
        with:
          token: ${{ secrets.ABOUTTHEAPP_TOKEN }}
          alias: rezervace
          version: ${{ steps.release.outputs.version }}
          changelog-source: git-log
          changelog-since: ${{ steps.release.outputs.previous-tag }}
          version-visibility: public
          customer-alias: klient
          environment: production

5. Poznámky k vydání z commitů nebo z CHANGELOG.md

Pokud použijete parametr changelog-source: git-log, sestaví se poznámky k vydání z commitů mezi předchozím tagem a aktuálním, bez merge commitů, text každého commitu bude jako odrážka. Protože u prvního vydání předchozí tag neexistuje, verze se zapíše bez poznámek.

Pokud poznámky píšete ručně do souboru CHANGELOG.md ve formátu Keep a Changelog, použijte changelog-source: file. Akce z něj použije sekci, jejíž nadpis odpovídá verzi, třeba ## [1.4.2] - 2026-11-05. Jak mají vypadat dobré poznámky se dočtete v šabloně poznámek k vydání.

6. Ověření, že nasazená aplikace běží v nové verzi

Ověření nasazení zapnete parametrem verify-url. Akce pak před zápisem verze opakovaně volá adresu nasazené aplikace, dokud nedostane odpověď o nasazené verzi. Pokud ji aplikace do 300 sekund nevrátí, krok selže a nezapíše nic.

Odpověď může být JSON, například {"version": "1.4.2"} nebo prostý text s verzí na prvním řádku. Pokud nevíte, jak dostat verzi do buildu, přečtěte si článek Jak zobrazit verzi aplikace. Adresa musí být dostupná z runneru bez přihlášení a vrácená hodnota se musí přesně shodovat s verzí.

          verify-url: https://rezervace.example.com/version.json
          verify-timeout: 300

7. Staging, produkce a více zákazníků

Staging a produkci rozdělte v GitHub Actions na dva joby. Job staging nasadí na staging automaticky, job production nastavte tak, ať má needs: staging a vlastní environment se schvalovatelem, takže na produkci se nasadí až po schválení. Každý job má vlastní krok abouttheapp/sync se správnou hodnotou environment.

Stejně to funguje u aplikace, kterou provozujete pro více zákazníků. Pro každého zákazníka a prostředí zapište instalaci zvlášť, samostatným krokem nebo pomocí matrix strategie přes seznam aliasů zákazníků. Zápis verze je idempotentní, opakované spuštění ji jen aktualizuje. Zápis instalace verze se však přidává při každém běhu, takže opakované spuštění workflow zapíše do AboutTheApp další nasazení.

8. Kde uvidíte výsledek

Zapsaná verze se objeví v katalogu verzí produktu v dashboardu i s poznámkami k vydání. Veřejná verze se zobrazí na About page v záložce Verze produktu. About box v aplikaci zobrazí aktuální verzi i s poznámkami.

Zákaznická About page ukazuje v záložce Prostředí a verze, která verze běží u zákazníka na stagingu a na produkci a kdy se nasadila. Podpora i zákazník tak vidí verzi, kterou zákazník skutečně používá, a může vidět i stav na ostatních prostředích.

Časté otázky