--- title: "Wdrożenia WordPress bez przestojów dzięki Trellis: atomic deploy w praktyce" url: "https://helloblog.io/pl/wdrozenia-wordpress-bez-przestojow-dzieki-trellis/" date: "2025-10-02" modified: "2026-01-20" author: "Piotr Kowalski" language: "pl_PL" categories: ["DevOps"] tags: ["Bedrock", "Deploy", "DevOps", "Trellis", "WordPress"] featured_image: "https://helloblog.io/app/uploads/sites/8/2026/01/featured-2-1024x572.png" excerpt: "Klasyczne deploye WordPressa potrafią „rozsypać” stronę na kilka minut, bo nadpisujesz pliki na żywo. Trellis rozwiązuje to atomic deploymentem: nowa wersja powstaje obok, a przełączenie jest natychmiastowe." --- # 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/ ``` 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 ``` 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](https://roots.io/bedrock/) (czytelniejsza struktura i zarządzanie zależnościami). 2. Dodaj [Trellis](https://roots.io/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. #### Warto zapamiętać Trellis można używać wyłącznie do wdrożeń Bedrockowych projektów — bez zmiany lokalnego środowiska. To częsty model, gdy zespół ma już ułożony development, a chce „tylko” bezpieczniejszych deployów i rollbacków. ## 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. ## Odniesienia / Źródła - [Zero Downtime WordPress Deployments with Trellis](https://roots.io/zero-downtime-wordpress-deployments-with-trellis/) - [Trellis Deployments Documentation](https://roots.io/trellis/docs/deployments/) - [Bedrock](https://roots.io/bedrock/) - [Trellis](https://roots.io/trellis/) - [Creating and running Laravel migrations (Acorn docs)](https://roots.io/acorn/docs/creating-and-running-laravel-migrations/)