Jak vytvořit CI/CD pipeline od nuly: Průvodce pro začátečníky

Vytvořte si svůj první CI/CD pipeline od nuly

Vytvoření prvního CI/CD pipeline se může zdát jako náročný úkol, zvláště když jsou produkční systémy složité a riskantní pro experimenty. Základní principy jsou však překvapivě jednoduché: pipeline je prostě automatizovaný proces, který nainstaluje závislosti, spustí testy a sestaví vaši aplikaci v čistém, reprodukovatelném prostředí. Tento průvodce vás provede základními koncepty a praktickými kroky potřebnými pro vytvoření CI/CD pipeline od nuly, čímž přemění ruční a chybová nasazení na spolehlivý automatizovaný pracovní postup.

Nepotřebujete Kubernetes ani produkční systém, abyste si procvičili CI/CD. Začněte s malým projektem, Git repozitářem a CI nástrojem, jako je GitHub Actions, GitLab CI nebo Jenkins. Nejdůležitějším krokem je zajistit, aby váš build byl reprodukovatelný lokálně, než napíšete byť jen jeden řádek konfigurace pipeline.

Základ: Reprodukovatelnost je klíčem k úspěchu

Než napíšete první soubor pipeline, váš projekt by se měl sestavit od nuly. Pokud se to nepodaří na čerstvém klonu repozitáře, nepodaří se to ani v CI.

Krok 1: Zajistěte reprodukovatelnost lokálního buildu

Zlaté pravidlo je zajistit, aby se vaše aplikace úspěšně sestavila od čistého stolu na lokálním počítači. Například:

• Node.js: npm ci && npm test && npm run build
• Python: pip install -r requirements.txt && pytest
• Go: go test ./... && go build

Krok 2: Uzamkněte lock soubory

Lock soubory (např. package-lock.json, go.sum nebo Pipfile.lock) jsou nezbytné pro deterministické sestavení. Bez nich by váš CI pipeline mohl nainstalovat jiné verze závislostí, než které byly použity lokálně, což by vedlo k nepředvídatelným selháním testů. V Node.js příkaz npm ci striktně dodržuje lock soubor, čímž zabraňuje takovému "driftu závislostí".

Napsání prvního pipeline

S reprodukovatelným buildem můžete proces automatizovat. Základní pipeline se skládá ze tří fází: sestavení, testování a nasazení.

Krok 3: Vyberte CI/CD nástroj

Váš výběr často závisí na tom, kde je uložen váš kód. Zde jsou tři běžné možnosti:

Nástroj	K čemu se nejlépe hodí	Definice pipeline	Možnost vlastního hostingu
GitHub Actions	Projekty již na GitHubu, veřejné repozitáře (zdarma).	.github/workflows/*.yml	Ano (Self-hosted runners)
GitLab CI	All-in-one DevOps platforma s hostingem Gitu.	.gitlab-ci.yml	Ano (GitLab CE)
Jenkins	Vysoká přizpůsobitelnost, zralý ekosystém, složitá logika sestavení.	Jenkinsfile (Groovy)	Ano (přes Java, založeno na pluginech)

Krok 4: Vytvořte minimální konfiguraci pipeline

Definice pipeline je YAML nebo Groovy soubor v kořenu vašeho repozitáře, který říká CI runneru, co má dělat.

Příklad: .gitlab-ci.yml (GitLab CI) Tento kód definuje pipeline, který sestaví Go aplikaci, uloží binární soubor jako artifact a poté jej spustí v další fázi.

default:
  image: golang

stages:
  - build
  - run

build go:
  stage: build
  script:
    - go build
  artifacts:
    paths: 
      - array

run go:
  stage: run
  script:
    - ./array

Příklad: Jenkinsfile (deklarativní pipeline) Dělá totéž, ale používá Docker image pro spuštění Node.js aplikace.

pipeline {
    agent { docker { image 'node:20-alpine' } }
    stages {
        stage('Build') {
            steps { sh 'npm ci && npm run build' }
        }
        stage('Test') {
            steps { sh 'npm run test' }
        }
    }
}

⚠️ Bezpečnostní upozornění: Nikdy nehardcodujte proměnné prostředí, jako jsou URL databází nebo API klíče, do vašeho repozitáře. Použijte vestavěný správce tajemství vašeho CI nástroje (proměnné GitLab CI, Jenkins credentials nebo GitHub Actions secrets) pro jejich vložení do vašich úloh.

Sdílení dat mezi fázemi

Klíčovou vlastností moderních pipeline je možnost sdílet data mezi úlohami. Bez toho byste museli aplikaci znovu sestavovat v každé fázi, což by plýtvalo časem a prostředky.

Krok 5: Používejte artifacts

Artifacts jsou soubory nebo adresáře uložené z jedné úlohy a dostupné pro následující úlohy. V příkladu s GitLab CI ukládá úloha build go binární soubor array. Úloha run go pak tento binární soubor automaticky stáhne a použije bez nutnosti překompilování.

Automatizace nasazení (volitelné)

Jakmile CI funguje, můžete přidat kontinuální nasazování. Princip je jednoduchý: nasazení by měla probíhat pouze po úspěšném průchodu testů.

Krok 6: Implementujte základní strategii nasazení

Pro jednoduché aplikace může SSH příkaz zkopírovat soubory na váš server.

Příklad: Nasazení pomocí rsync

deploy:
  stage: deploy
  image: alpine:latest
  only:
    - main
  script:
    - apk add --no-cache openssh-client rsync
    - rsync -avz --delete dist/ deploy@yourserver:/var/www/app/

Pokud používáte kontejnery, fáze nasazení obvykle zahrnuje sestavení Docker image, jeho odeslání do registru a poté použití SSH k provedení docker compose pull && docker compose up -d na produkčním serveru.

Praxe a odstraňování problémů

Čtení o CI/CD nestačí. Abyste se skutečně naučili, musíte spouštět pipeline a záměrně je rozbíjet.

Krok 7: Záměrně rozbíjejte věci, abyste se učili

Zde dochází ke skutečnému porozumění. Zkuste následující experimenty:

1. Odstraňte deklaraci závislosti. Spadne CI? Proč?
2. Odstraňte lock soubor. Způsobí drift verzí rozbití buildu?
3. Přidejte nestabilní test. Projde lokálně, ale selže v CI? To často odhalí rozdíly v čistém CI prostředí.

Krok 8: Používejte reporty o testech a logy

CI by měl poskytovat přehled o tom, které testy selhaly, které jsou pomalé a které jsou nestabilní. Používejte logy nejen k hledání chyb, ale také k pochopení celého procesu: jak dlouho trvá instalace závislostí? Kde přesně dochází k selhání buildu?

Často kladené otázky

Jak dlouho trvá vytvoření prvního CI/CD pipeline? Pro jednoduchý projekt lze základní pipeline spustit za méně než hodinu. V praktickém průvodci GitLab CI je odhadovaný čas pro základní pipeline 15 minut. Čas se obvykle stráví psaním konfiguračního souboru a odstraňováním problémů s reprodukovatelností.

Měl by si začátečník vybrat Jenkins, GitHub Actions nebo GitLab CI? Pokud je váš kód na GitHubu, GitHub Actions je přirozenou volbou. Pro all-in-one platformu je skvělý GitLab CI. Jenkins je neuvěřitelně výkonný, ale má strmější křivku učení a vyžaduje více údržby, takže se hodí spíše pro větší a složitější konfigurace.

Jaký je rozdíl mezi artifactem a cache v CI/CD? Artifacts se používají k přenosu souborů mezi fázemi (např. přenos zkompilovaného binárního souboru z fáze sestavení do fáze nasazení). Cache se používají k urychlení sestavení opětovným použitím souborů, jako jsou závislosti (node_modules), mezi různými běhy pipeline.

Proč mé testy procházejí lokálně, ale selhávají v CI pipeline? Obvykle je to známka driftu prostředí. Na vašem lokálním počítači mohou být jiné verze softwaru nebo proměnné prostředí. Proto je uzamčení lock souborů tak důležité a proč je spuštění projektu z čistého klonu lokálně nezbytným prvním krokem.

Potřebuji Docker k vytvoření CI/CD pipeline? Striktně řečeno ne, ale je to důrazně doporučeno. Spouštění úloh uvnitř Docker kontejnerů zajišťuje izolaci a reprodukovatelnost. Zaručuje, že každá úloha běží v čistém, známém prostředí, čímž se zabrání vzájemnému ovlivňování úloh a znečištění hostitelského serveru.

— Editorial Team