Optimalizácia CI/CD pipeline v GitLabe: Cache, paralelizácia a build artefakty

V predchádzajúcom článku sme si ukázali, ako postaviť základnú GitLab CI/CD pipeline s E2E testami. Teraz sa pozrieme na to, ako ju zrýchliť a zefektívniť pomocou cache, artefaktov a paralelného spúšťania jobov.

🚀 Prečo optimalizovať pipeline?

• ⏱ Menej čakania = rýchlejšia spätná väzba pre vývojárov
• 🔄 Menší výpočtový čas = úspora CI minút a zdrojov
• 🔍 Menej „zbytočných“ krokov = lepšia čitateľnosť a udržiavateľnosť pipeline

📦 Použitie cache v GitLabe

Cache umožňuje uchovať si súbory medzi rôznymi spusteniami pipeline – typicky node_modules alebo buildy.

cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - node_modules/

💡 Pozor: Cache sa správa inak ako artifacts – je zdieľaná medzi jobmi a behmi.

📁 Artifacts – prenos súborov medzi jobmi

Ak chceš, aby výstup z jedného jobu (napr. build) bol dostupný v ďalšom (napr. testy), použi artifacts:

build:
  stage: build
  script:
    - npm run build
  artifacts:
    paths:
      - dist/

Potom sa dist/ automaticky prenesie do ďalšieho jobu, ak je v ďalšom stage.

🧵 Paralelizácia jobov

GitLab pipeline beží po stage-och. V rámci každého stage môžeš spustiť viacero jobov naraz:

stages:
  - test

test:unit:
  stage: test
  script:
    - npm run test:unit

test:lint:
  stage: test
  script:
    - npm run lint

Tieto dva joby sa spustia súbežne – ak máš runner s dostatočnou kapacitou.

🧠 Tipy pre optimalizáciu

• Rozdeľ testy do viacerých jobov (unit, e2e, lint...)
• Nepoužívaj npm install zbytočne v každom kroku – kombinuj cache a artifacts
• Pre dlhé buildy použi only: changes – napr. buildovať iba pri zmene frontendu

🧩 Bonus: merge request pipelines

Môžeš spúšťať pipeline len pre MR a PR:

only:
  - merge_requests

Pomáha to odlíšiť vývojové a produkčné nasadenia.

🧾 Záver

Ak CI pipeline trvá 15+ minút, vývojári začnú strácať pozornosť. Optimalizácia pomocou cache, artefaktov a paralelizácie ti môže ušetriť minúty pri každom commite – čo sa pri aktívnom tíme násobí každý deň.

V ďalšom článku si ukážeme, ako vytvoriť samostatný stage pre nasadenie (napr. na Vercel, Firebase alebo VPS) a ako použiť schvaľovanie deployov.