Testy i CI/CD Magento 2 – GitHub Actions, Deployer, PHPUnit

Magento 2 to złożona platforma – każde wdrożenie wymaga kompilacji DI, generowania statycznych plików, migracji bazy danych i czyszczenia cache. Ręczna realizacja tych kroków to pewna droga do błędów i nieprzewidywalnego stanu produkcji. Dobrze skonfigurowany pipeline CI/CD eliminuje zmienność ludzką i sprawia, że każde wdrożenie jest powtarzalne, audytowalne i odwracalne.

GitHub Actions – automatyczne testy i build

GitHub Actions to darmowe środowisko CI wbudowane w repozytorium. Każdy push na branch main lub develop automatycznie uruchamia pipeline: instalację zależności, testy jednostkowe PHPUnit, analizę statyczną PHPCS i – w razie sukcesu – deployment przez Deployer na serwer docelowy.

Pro Tip: Kompletny plik .github/workflows/deploy.yml

Gotowy workflow GitHub Actions dla Magento 2: testy → PHPCS → deployment przez Deployer. Sekrety SSH i klucze trzymaj w GitHub Secrets, nigdy w repozytorium.

# .github/workflows/deploy.yml

name: Magento CI/CD

on:

push:

branches: [main]

jobs:

test-and-deploy:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- uses: shivammathur/setup-php@v2

with: { php-version: '8.3' }

- run: composer install --no-interaction --prefer-dist

- run: vendor/bin/phpunit -c dev/tests/unit/phpunit.xml.dist --testdox

- run: vendor/bin/phpcs --standard=Magento2 app/code/Vendor/

- name: Deploy via Deployer

env:

DEPLOY_KEY: $${{ secrets.SSH_PRIVATE_KEY }}

run: |

echo "$DEPLOY_KEY" > /tmp/deploy_key && chmod 600 /tmp/deploy_key

vendor/bin/dep deploy production -vvv

Deployer PHP – zero-downtime deployment

Deployer (deployer.org) to najlepszy narzędzie do wdrażania Magento 2. Działa na zasadzie atomic symlink swap: nowa wersja aplikacji jest przygotowywana w osobnym katalogu releases/, a po zakończeniu wszystkich kroków (composer install, static deploy, setup:upgrade) serwer produkcyjny przez zmianę symlinku current/ natychmiast przełącza się na nową wersję. Cały proces trwa milisekundy i jest w pełni odwracalny – rollback to jeden rozkaz.

Konfiguracja Deployer dla Magento 2 (deploy.php)

Deployer ma oficjalny przepis dla Magento 2 (deployer/magento2-deployer). Poniżej minimalna konfiguracja produkcyjna z zachowaniem współdzielonych plików i katalogów.

// deploy.php – konfiguracja Deployer dla Magento 2

require 'recipe/magento2.php';

host('production')

->setHostname('1.2.3.4')

->setRemoteUser('deploy')

->setIdentityFile('/tmp/deploy_key')

->setDeployPath('/var/www/sklep');

set('shared_files', ['.env', 'app/etc/env.php']);

set('shared_dirs', ['var', 'pub/media', 'pub/static']);

set('writable_dirs', ['var', 'pub/media', 'pub/static', 'generated']);

set('keep_releases', 5); // trzymaj 5 ostatnich release’ów

// Niestandardowe zadania w pipeline:

after('deploy:failed', 'deploy:unlock'); // odblokuj przy błędzie

# Deployment na produkcję (wywołanie z GitHub Actions lub ręcznie):

vendor/bin/dep deploy production -vvv

# Natychmiastowy rollback do poprzedniej wersji:

vendor/bin/dep rollback production

PHPUnit i analiza statyczna – jakość kodu przed wdrożeniem

Każdy commit do main powinien przejść przez trzy warstwy kontroli jakości: testy jednostkowe (PHPUnit), analizę statyczną (PHPStan/Psalm) i styl kodowania (PHP_CodeSniffer z Magento2 standard). Pipeline nie powinien wdrażać, jeśli którykolwiek krok zwróci błąd. To gwarantuje, że na produkcji ląduje wyłącznie kod, który przeszedł pełną inspekcję.

Testy i analiza statyczna – komendy CLI

Pełen zestaw komend, które powinny być wywoływane w pipeline przed każdym deploymentem.

# Testy jednostkowe PHPUnit z raportem testdox:

vendor/bin/phpunit -c dev/tests/unit/phpunit.xml.dist --testdox --colors=always

# Testy integracyjne (wymagają bazy danych testowej):

vendor/bin/phpunit -c dev/tests/integration/phpunit.xml.dist

# Analiza statyczna PHPStan (poziom 5 = dobry punkt startowy):

vendor/bin/phpstan analyse app/code/Vendor/ --level=5 --no-progress

# Standardy kodowania Magento 2 (PHPCS):

vendor/bin/phpcs --standard=Magento2 --extensions=php app/code/Vendor/

# Automatyczna naprawa stylu kodu (PHP CS Fixer):

vendor/bin/php-cs-fixer fix app/code/Vendor/ --dry-run --diff

Kroki wdrożenia Magento 2 w pipeline

Kolejność kroków w deployment pipeline ma znaczenie – zła kolejność może doprowadzić do chwilowego wyświetlania błędów na produkcji. Poniższy przepis zapewnia, że serwer jest w trybie konserwacji w czasie najbardziej ryzykownych operacji.

1. maintenance:enable

Uruchom tryb konserwacji przed jakimkolwiek krokiem dotykającym bazy. Użyj --ip aby zachować dostęp dla dev.

2. composer install --no-dev

Zainstaluj zależności produkcyjne. Nigdy nie commituj katalogu vendor/ do repozytorium.

3. setup:upgrade + compile

Migracje bazy i kompilacja DI. Najbardziej czasochłonne kroki – w Deployer wykonywane na nowym release przed swap.

4. static-content:deploy

Generowanie JS/CSS dla wszystkich locale. Użyj flagą -j4 (parallel threads) dla przyspieszenia.

5. symlink swap (Deployer)

Atomic swap: current/ zaczyna wskazywać na nowy release. Zero-downtime – użytkownicy nie widzą przerwy.

6. cache:flush + maintenance:disable

Wyczyść Redis i Varnish, wyłącz tryb konserwacji. W Deployer użyj after('deploy', 'magento:cache:flush').

Najczęstsze błędy w pipeline CI/CD

Deployment zawiesza się na static:deploy

Za mało pamięci PHP w GitHub Actions. Ustaw memory_limit=-1 lub podziel deploy na osobne locale.

Rollback nie cofa migracji bazy

Deployer cofa pliki, ale nie migracje DB. Zawsze pisz migracje wstecznie zgodne lub rób backup przed deploymentem.

Błąd "deploy:lock" blokuje kolejne wdrożenia

Poprzedni deployment się nie udał, ale nie zwolnił blokady. Uruchom: dep deploy:unlock production.

env.php nadpisywany przez Deployer

Brak app/etc/env.php w shared_files. Plik jest usuwany przy każdym deploymencie. Konfiguracja znika z produkcji.

Sekrety w historii commitów

Klucze API lub hasła commitowane do repozytorium. Używaj GitHub Secrets i .gitignore dla env.php.

Testy integracyjne nie działają w CI

Brak serwisu MySQL w GitHub Actions workflow. Dodaj: services: mysql: image: mysql:8.0 w pliku YAML.

Pełna lista komend wdrożeniowych Magento 2

Kolejność ma znaczenie. Te komendy w tej kolejności – nic nie pójdzie nie tak na produkcji.

# 1. Tryb konserwacji (zachowaj IP dewelopera):

php bin/magento maintenance:enable --ip=TWOJE_IP

# 2. Zależności produkcyjne:

composer install --no-dev --optimize-autoloader --no-interaction

# 3. Migracje + kompilacja DI:

php bin/magento setup:upgrade --keep-generated

php bin/magento setup:di:compile

# 4. Pliki statyczne (parallel, wszystkie locale):

php bin/magento setup:static-content:deploy -f pl_PL en_US de_DE -j4

# 5. Uprawnienia + cache:

find var generated pub/static pub/media app/etc -type f -exec chmod g+w {} + 2>/dev/null

php bin/magento cache:flush

# 6. Wyłączenie konserwacji:

php bin/magento maintenance:disable

CI/CD to inwestycja, która zwraca się przy pierwszym unikniętym incydencie produkcyjnym. W Mage24.pl każdy projekt produkcyjny otrzymuje od nas skonfigurowany pipeline GitHub Actions + Deployer z automatycznym rollbackiem, testami i monitoringiem wdrożeń.

CI/CD: Wdrażaj Kod Bez Strachu