Preskočiť na obsah
DevOps Laravel 30. jún 2026 · 11 min čítania

GitHub Actions CI/CD pre Laravel

Manuálny deploy cez FTP alebo ručné git pull na serveri funguje, kým niekto zabudne spustiť migráciu alebo nahrá nehotový kód na produkciu. Automatizovaná pipeline spustí testy pred každým nasadením a deployuje len kód, ktorý prešiel — bez výpadku a bez ručných krokov.

DC

Dušan Chlpek

PHP vývojár, GEAR s.r.o. · 25+ rokov praxe

Prečo automatizovať nasadenie

Pri manuálnom deploye sa zodpovednosť za poradie krokov (testy, migrácie, cache, restart workerov) presúva na človeka — a človek niekedy krok vynechá. Pipeline v GitHub Actions vykoná rovnaké kroky v rovnakom poradí pri každom push, bez výnimky, a zlyhanie ktoréhokoľvek kroku zastaví celý deploy skôr, než sa rozbitý kód dostane na produkciu.

Architektúra pipeline: od commitu po produkciu

Bežná pipeline pre Laravel appku má štyri fázy, ktoré idú postupne za sebou:

  1. Checkout a závislosti — stiahnutie kódu, composer install, npm ci
  2. Testy — Pest alebo PHPUnit testovacia sada proti testovacej databáze
  3. Build — kompilácia frontend assetov (npm run build)
  4. Deploy — nahranie kódu na server cez SSH/rsync, migrácie, cache warm-up

Fáza deploy sa spustí len ak fázy testov a buildu prešli bez chyby — to je celý zmysel pipeline.

Workflow YAML

name: Deploy

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
          extensions: mbstring, pdo_mysql, redis
          coverage: none

      - name: Install Composer dependencies
        run: composer install --no-interaction --prefer-dist --optimize-autoloader

      - name: Copy .env
        run: cp .env.testing .env

      - name: Generate app key
        run: php artisan key:generate

      - name: Run Pest tests
        run: php artisan test

  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install Node dependencies a build assetov
        run: |
          npm ci
          npm run build

      - name: Nasadenie cez SSH
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /var/www/myapp
            bash deploy.sh

Job deployneeds: test — GitHub Actions ho nespustí, pokiaľ testovací job neskončí úspechom.

GitHub Secrets: čo do nich patrí

Citlivé hodnoty (SSH klúč, heslá, API tokeny) sa nikdy neukladajú priamo do workflow súboru ani do repozitára. V nastaveniach repozitára (Settings → Secrets and variables → Actions) sa definujú ako zašifrované premenné, dostupné v pipeline cez ${{ secrets.NAZOV }}.

Pozor: Súbor .env sa nikdy nesmie commitnúť do repozitára — obsahuje produkčné heslá k databáze a API klúče. Pre SSH deploy klúč vytvorte samostatný, len na deploy účel, s prístupom len do adresára aplikácie (princíp najmenších oprávnení).

Nasadenie bez výpadku: releases a symlink

Priamy git pull do produkčného adresára znamená, že počas sťahovania zmien môže requester dostať polovičný stav appky. Riešením je nahrávať každú verziu do nového adresára a prepnúť symlink až po dokončení všetkých krokov:

# deploy.sh na serveri
RELEASE=releases/$(date +%Y%m%d%H%M%S)
mkdir -p $RELEASE
cp -r current/. $RELEASE/
cd $RELEASE

git pull origin main
composer install --no-dev --optimize-autoloader
php artisan migrate --force
php artisan config:cache
php artisan route:cache
php artisan view:cache

cd ..
ln -sfn $RELEASE current   # Atomické prepnutie symlinku
php artisan queue:restart  # Workery zoberú nový kód pri ďalšom jobe

Príkaz ln -sfn prepne symlink atomicky — requesty počas prepínania dostanú buď úplne starú, alebo úplne novú verziu, nikdy zmiešanú.

Migrácie v pipeline — opatrne

Pozor: migrate --force v automatizovanej pipeline spustí migrácie bez interaktívneho potvrdenia. Pri migráciách, ktoré menia veľké tabuľky (napr. ALTER TABLE na miliónoch riadkov), zvážte spustenie migrácie manuálne mimo pipeline alebo s explicitným maintenance oknom — automatický deploy nie je miesto na experimentovanie s rizikovou zmenou databázovej schémy.

Cache warm-up a queue restart po deployi

Po každom nasadení treba znova vygenerovať cache, ktorá obsahuje skompilovanú konfiguráciu, routy a views z predošlej verzie kódu:

Bez queue:restart by queue workery (spustené ako dlhotrvajúci proces, podobne ako pri Octane) ďalej obsluhovali starý kód v pamäti.

Notifikácie o nasadení

Krok navyše v deploy jobe odošle správu do Slacku alebo Discordu po úspešnom (alebo neúspešnom) nasadení — tím okamžite vie, že nová verzia je na produkcii:

- name: Notifikácia do Slacku
  if: always()
  uses: slackapi/slack-github-action@v1.27.0
  with:
    payload: |
      {
        "text": "Deploy ${{ job.status }}: ${{ github.sha }}"
      }
  env:
    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
Tip: Podmienka if: always() zabezpečí, že notifikácia sa odošle aj pri zlyhaní deploy jobu — to je presne ten prípad, kedy chcete vedieť o probléme najrýchlejšie.

Záver: checklist pred zapnutím pipeline

Chcete automatizovať nasadenie vašej aplikácie?

Nastavím CI/CD pipeline na mieru — testy, zero-downtime deploy aj notifikácie, presne podľa vašej infrastruktúry. Dopyt bez záväzkov, odpoveď do 24 hodín.

Ďalšie články

Zavolať E-mail Dopyt

Ochrana súkromia

Táto stránka využíva cookies pre nevyhnutné fungovanie. Rešpektujeme vaše súkromie a legislatívu GDPR.