Přeskočit na obsah
_CORE
AI & Agentic Systems Core Informační Systémy Cloud & Platform Engineering Data Platforma & Integrace Security & Compliance QA, Testing & Observability IoT, Automatizace & Robotika Mobile & Digital Banky & Finance Pojišťovnictví Veřejná správa Obrana & Bezpečnost Zdravotnictví Energetika & Utility Telco & Média Průmysl & Výroba Logistika & E-commerce Retail & Loyalty
Reference Technologie Blog Knowledge Base O nás Spolupráce Kariéra
Pojďme to probrat

GitHub Actions — moderní CI/CD pipeline

22. 03. 2020 3 min čtení CORE SYSTEMSdevops

GitHub Actions vyšly z beta verze koncem roku 2019 a v roce 2020 se stávají reálnou alternativou k Jenkins, GitLab CI i Azure DevOps. Vyzkoušeli jsme je na třech projektech — tady jsou naše zkušenosti.

Proč GitHub Actions v roce 2020

Jenkins je mocný, ale jeho údržba je práce na plný úvazek. Plugin hell, Groovy scripty, které nikdo nechce debugovat, a UI z roku 2005. GitLab CI je elegantní, ale vyžaduje GitLab. Pokud váš kód žije na GitHubu — a v roce 2020 tam žije kód většiny týmů — dává Actions perfektní smysl.

Hlavní výhody:

  • Native integrace: CI/CD žije přímo v repozitáři, ne na separátním serveru
  • YAML konfigurace: verzovaná, reviewovatelná, mergeable — jako kód
  • Marketplace: tisíce hotových actions od komunity — od cache po deployment
  • Matrix builds: testujte na více OS/verzích paralelně bez složité konfigurace
  • Free tier: 2000 minut/měsíc pro veřejné repozitáře, 2000 pro private (Team plan)

Anatomie workflow souboru

Vše začíná souborem v .github/workflows/. Základní struktura pro .NET Core aplikaci:

name: CI Pipeline

on:

push:

branches: [ main, develop ]

pull_request:

branches: [ main ]

jobs:

build-and-test:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v2

- uses: actions/setup-dotnet@v1

with:

dotnet-version: ‘3.1.x’

- run: dotnet restore

- run: dotnet build –no-restore

- run: dotnet test –no-build

Přehledné, čitelné, verzované. Žádný klikací wizard, žádné „kdo změnil ten Jenkins job?”. Pull request na workflow soubor projde stejným review jako aplikační kód.

Secrets management

GitHub Secrets jsou šifrované na úrovni repozitáře nebo organizace. V workflow se k nim přistupuje přes ${{ secrets.NAZEV }}. Pro deployment credentials (Azure service principal, AWS keys, Docker registry) je to čisté řešení bez externích vault systémů.

Pro komplexnější scénáře — rotace klíčů, dynamické secrets — kombinujeme GitHub Secrets s Azure Key Vault. Action azure/login@v1 se autentizuje přes service principal a stáhne aktuální secrets z Key Vault. Dvě vrstvy zabezpečení, automatická rotace.

Reálný deployment pipeline

Na projektu pro logistickou firmu jsme nasadili kompletní pipeline:

  1. PR check: build + unit testy + linting (ESLint, Prettier) — blokuje merge při selhání
  2. Build artifact: Docker image, push do Azure Container Registry
  3. Deploy to staging: automaticky po merge do develop — Azure Web App for Containers
  4. Integration testy: Postman/Newman kolekce běží proti staging prostředí
  5. Deploy to production: manuální approval přes GitHub Environments, pak rolling update

Celý pipeline od push do production: ~12 minut. S Jenkins to bylo 25+ minut a vyžadovalo dedikovaný build server.

Matrix strategie pro cross-platform

Knihovna, kterou dodáváme klientům pro integraci s jejich systémy, musí běžet na .NET Core 3.1 i .NET Framework 4.8, na Windows i Linuxu. Matrix build to řeší elegantně:

strategy:

matrix:

os: [ubuntu-latest, windows-latest]

dotnet: [‘3.1.x’, ‘5.0.x’]

fail-fast: false

Čtyři kombinace běží paralelně. Výsledek za 4 minuty místo 16 sekvenčně. A fail-fast: false znamená, že i když jedna kombinace selže, ostatní doběhnou — víte přesně, kde je problém.

Self-hosted runners — kdy a proč

GitHub-hosted runners jsou pohodlné, ale mají limity: 7 GB RAM, 14 GB disk, žádný přístup k interní síti. Pro build velkých .NET solution (50+ projektů) nebo pro deployment do on-premise prostředí potřebujete self-hosted runner.

Nasadili jsme runner jako Docker container na Azure Container Instance — ephemeral, škálovatelný, s přístupem do klientovy VNet přes VNet integration. Runner se spustí, provede job, a zanikne. Čistý stav pro každý build, žádný state drift.

Srovnání s Jenkins a GitLab CI

  • Jenkins: nejvíc flexibility, ale nejvíc údržby. Vhodný pro enterprise s dedikovaným DevOps týmem a legacy integrací
  • GitLab CI: výborný pokud používáte GitLab. Tighter integrace, built-in registry, security scanning. Ale vendor lock-in
  • GitHub Actions: nejlepší developer experience, rychlý start, skvělý pro týmy na GitHubu. Méně vyzrálý pro komplexní enterprise scénáře (v roce 2020)

Actions jako výchozí volba pro nové projekty

Pro nové projekty v roce 2020 doporučujeme GitHub Actions jako výchozí CI/CD platformu. Nižší provozní náklady, lepší developer experience a dostatečná flexibilita pro většinu scénářů. Jenkins necháme tam, kde už běží a funguje — migrace se musí vyplatit.

github actionsci/cddevopsautomatizace