Wdrożenia WordPress bez przestojów dzięki Trellis: atomic deploy w praktyce

W ekosystemie WordPressa wciąż zaskakująco często wdrożenie oznacza nadpisywanie plików na produkcji: przez FTP, przez rsync albo przez mechanizmy hostingu działające podobnie „w miejscu”. To działa… dopóki nie trafisz na moment, w którym użytkownik dostanie mieszankę starych i nowych plików, a Ty oglądasz błędy w logach.

Trellis (projekt od Roots) podchodzi do tematu jak nowoczesne aplikacje webowe: wdrożenie ma być bez przestoju (zero downtime), a przełączenie wersji ma zajść atomowo. Co ważne, nie musisz migrować całego workflow do Trellisa. Sporo zespołów używa go wyłącznie jako narzędzia do wdrożeń (szczególnie dla projektów opartych o Bedrock), a lokalnie pracuje w Valet, Lando, DDEV czy czymkolwiek innym.

Co w praktyce znaczy „zero downtime” przy deployu?

Zero downtime deployments to taki sposób publikacji nowej wersji, w którym serwis pozostaje dostępny i funkcjonalny przez cały proces. Klucz jest prosty: nie podmieniasz plików w katalogu, z którego serwuje web server. Zamiast tego przygotowujesz kompletną, nową wersję w izolacji i dopiero na końcu przełączasz ruch na nowy release.

Dzięki temu nie ma „okna”, w którym WordPress próbuje ładować np. nowy plik PHP i stary plik z funkcjami, albo nową wersję tematu i starą wersję zależności z vendor/.

Dlaczego tradycyjne wdrożenia WordPressa są ryzykowne?

Najpopularniejsze podejścia mają wspólny problem: aktualizują pliki w miejscu, gdy strona już działa.

• FTP: ręczne wrzucanie zmian i nadpisywanie plików. Wolne, podatne na pomyłki, a w trakcie uploadu użytkownicy mogą widzieć błędy.
• Synchronizacja plików (np. rsync): szybciej niż FTP, ale zasada ta sama — podmieniasz część plików, gdy reszta jeszcze jest stara.
• Deploy „wtyczką” od hostingu: wygodne, ale często bez realnego rollbacku i nadal z aktualizacją in-place.

W każdym z tych wariantów konsekwencje są podobne: chwilowe błędy 500, „znikające” assety, niedopasowane klasy/autoload, a w razie wpadki — stresujący powrót do poprzedniego stanu, zwykle ręczny.

Jak Trellis robi atomic deploy: katalogi wydań i jeden symlink

Trellis stosuje atomic deployment (wdrożenie atomowe): nowa wersja jest budowana jako kompletne, oddzielne wydanie, a przełączenie odbywa się przez aktualizację jednego dowiązania symbolicznego. Dodatkowo wdrożenia są immutable (niezmienne): raz opublikowany release nie jest modyfikowany w miejscu.

Struktura katalogów po deployu

/srv/www/example.com/
├── current/             # symlink do aktywnego wydania
├── releases/            # wszystkie wdrożone wydania
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # najnowsze
├── shared/              # współdzielone zasoby między wydaniami
│   └── uploads/
└── logs/

/srv/www/example.com/
├── current/             # symlink do aktywnego wydania
├── releases/            # wszystkie wdrożone wydania
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # najnowsze
├── shared/              # współdzielone zasoby między wydaniami
│   └── uploads/
└── logs/

Web server (np. Nginx) cały czas wskazuje na current/. A current/ to tylko symlink do konkretnego katalogu w releases/. Dzięki temu zmiana wersji sprowadza się do natychmiastowego przełączenia symlinka.

Co dzieje się podczas trellis deploy production

Pod spodem Trellis wykonuje serię kroków, które razem tworzą nowe wydanie bez dotykania działającej wersji aż do finału:

1. Initialize: przygotowanie struktury katalogów i utworzenie nowego katalogu release (znacznik czasu).
2. Update: pobranie najnowszego kodu z repozytorium Git do tymczasowego katalogu źródeł, poza „żywą” stroną.
3. Prepare: skopiowanie plików ze źródeł do nowego katalogu release.
4. Build: uruchomienie composer install i pobranie zależności PHP.
5. Share: podlinkowanie współdzielonych zasobów (np. uploads) z shared/ do nowego release.
6. Finalize: przełączenie current na nowy katalog release.

Najważniejszy efekt: w jednej chwili serwis działa na starym release, a w kolejnej — na nowym. Nie ma etapu pośredniego, w którym część plików jest „po update”, a część jeszcze nie.

Baza danych: zero downtime dla kodu ≠ automatyczne migracje

Atomic deploy świetnie rozwiązuje problem plików i zależności, ale baza danych to osobny temat. Zgodnie z dokumentacją Trellis: migracje schematu bazy nie są częścią standardowego deploya.

Jeżeli w projekcie używasz Acorn, możesz podejść do tego „po laravelowemu” i tworzyć migracje (Laravel migrations) dla WordPressa oraz uruchamiać je w ramach procesu wdrożenia. To pozwala uporządkować zmiany w DB, ale nadal wymaga świadomego planowania kompatybilności wstecznej (np. etapowego wprowadzania kolumn/indeksów).

Rollback w Trellis: powrót do poprzedniej wersji w sekundę

Przy wdrożeniach atomowych rollback przestaje być dramatem. Ponieważ każdy release to kompletny, niezmienny zestaw plików, powrót polega na przełączeniu current na wcześniejszy katalog.

trellis rollback production

trellis rollback production

Domyślnie na serwerze zostaje kilka ostatnich wydań (Trellis trzyma pięć najnowszych), więc zwykle masz pod ręką bezpieczną wersję, do której można wrócić natychmiast.

Hooki wdrożeniowe: jak dopasować deploy do realiów projektu

Trellis udostępnia hooki (punkty zaczepienia w procesie wdrożenia), które pozwalają dopiąć zadania przed i po kluczowych etapach. Przykładowo:

• deploy_build_before / deploy_build_after – własne kroki builda.
• deploy_finalize_before / deploy_finalize_after – zadania tuż przed przełączeniem i zaraz po nim.
• Hooki dla etapów: initialize, update, prepare, build, share, finalize.

To otwiera drogę do sensownych praktyk DevOpsowych nawet w klasycznych projektach WordPress: backup bazy przed wdrożeniem, czyszczenie cache po przełączeniu release, powiadomienia, czy szybkie smoke testy (sprawdzenie, czy serwis odpowiada poprawnie po wdrożeniu).

Jak zacząć: minimalna ścieżka do deployu bez przestojów

Najprostszy scenariusz wygląda tak:

1. Ułóż projekt w oparciu o Bedrock (czytelniejsza struktura i zarządzanie zależnościami).
2. Dodaj Trellis i ustaw konfigurację wdrożeń.
3. W wordpress_sites.yml wskaż repozytorium Git dla środowiska (np. production).
4. Uruchom deploy poleceniem trellis deploy production.

Pierwsze wdrożenie trwa dłużej, bo Trellis tworzy strukturę katalogów i instaluje zależności. Kolejne są szybsze — i przede wszystkim nie powodują przerw ani stanów pośrednich.

Podsumowanie: co realnie zyskujesz z Trellisowego atomic deploy?

• Brak przestojów i brak „mieszanki” plików podczas wdrożenia.
• Powtarzalny proces wdrożeniowy oparty o Git i budowanie release w izolacji.
• Rollback jako przełączenie symlinka, a nie ręczne odkręcanie zmian.
• Hooki do dopięcia backupów, cache purge, testów i innych kroków operacyjnych.