Jak organizować środowiska dev/stage/prod dla projektów WordPress

Praca nad projektem WordPress bez odpowiedniego workflow przypomina czasem spacer po polu minowym z zasłoniętymi oczami. Wrzucanie plików przez FTP prosto na produkcję? Wprowadzanie zmian w CSS na żywym organizmie i modlenie się, żeby nic nie wybuchło? Znamy to. Nazywam to „syndromem kowboja” – działa, dopóki nie przestanie. A kiedy przestanie, to zazwyczaj w spektakularny sposób w piątek o 17:00.

Dlatego dziś pogadamy o tym, jak poukładać procesy deweloperskie w świecie WordPressa, żeby spać spokojniej. Omówimy, jak prawidłowo rozdzielić środowiska deweloperskie, stagingowe i produkcyjne. Zastanowimy się, co powinno, a co absolutnie nie powinno lądować w repozytorium Git. Rozgryziemy też największą zagadkę wszechświata – jak sprawnie migrować bazę danych i media między tymi środowiskami. Zapnij pasy, bo robimy porządek w warsztacie!

Spis treści

1. Filozofia Trzech Środowisk: Dev, Stage i Prod
2. Git to Twój Najlepszy Przyjaciel: Co trzymać w repozytorium?
3. Święty Graal: Migracja Bazy Danych i Mediów
4. Automatyzacja, czyli Magia Deployu
5. Podsumowanie: Workflow na miarę XXI wieku

Filozofia Trzech Środowisk: Dev, Stage i Prod

Podstawą profesjonalnego podejścia jest praca na co najmniej trzech oddzielnych środowiskach. Każde z nich ma swój cel i traktowanie go inaczej to proszenie się o kłopoty.

• Dev (Środowisko deweloperskie / lokalne) – To Twój plac zabaw. Działa na Twoim komputerze (np. przy użyciu narzędzi jak Local, Docker czy MAMP). Tutaj możesz bezkarnie psuć, testować i eksperymentować. Nikt oprócz Ciebie tego nie widzi. Pełna swoboda, zero stresu.
• Stage (Środowisko testowe / staging) – To lustrzane odbicie produkcji. Powinno być skonfigurowane tak samo jak serwer produkcyjny (ta sama wersja PHP, te same rozszerzenia). Tutaj wgrywasz zmiany z lokalnego środowiska, aby przetestować je w warunkach „bojowych” i pokazać klientowi do akceptacji. To ostatni przystanek przed wielkim finałem.
• Prod (Środowisko produkcyjne) – Świętość. To jest strona, którą widzą użytkownicy. Nie dotykamy jej bezpośrednio! Jedyne zmiany, jakie tu trafiają, to te przetestowane i zatwierdzone na stagingu, wgrane za pomocą zautomatyzowanego procesu deploymentu.

Git to Twój Najlepszy Przyjaciel: Co trzymać w repozytorium?

Git to system kontroli wersji, który jest absolutną podstawą. Pozwala śledzić zmiany w kodzie, cofać je i współpracować w zespole. Ale kluczowe jest to, co do tego repozytorium wrzucamy.

Co trafia do repo? (Czyli „Kod”)

Zasadniczo, w repozytorium trzymamy wszystko, co jest kodem i konfiguracją projektu. Rzeczy, które tworzysz lub modyfikujesz jako deweloper.

• Twój motyw (i motyw potomny) – Cały katalog `wp-content/themes/twoj-motyw`.
• Twoje customowe wtyczki – Wszystkie wtyczki, które napisałeś specjalnie dla tego projektu.
• Pliki konfiguracyjne – Rzeczy takie jak `composer.json`, `package.json`, `.eslintrc`, `.gitignore`.
• Plik `.env` z przykładowymi zmiennymi – Nigdy nie wrzucaj pliku `.env` z danymi dostępowymi! Zamiast tego stwórz `.env.example` jako wzór.

Czego NIE wrzucamy do repo? (Czyli „Zależności i Treść”)

Repozytorium nie jest miejscem na wszystko. Unikaj wrzucania rzeczy, które są generowane automatycznie lub stanowią treść zarządzaną przez użytkownika.

• Rdzeń WordPressa (Core) – Nigdy nie wrzucaj całego WordPressa do repo. Zarządzaj nim za pomocą Composera lub skryptów.
• Wtyczki i motywy firm trzecich – Zamiast wrzucać ich kod, zarządzaj nimi przez Composer. Dzięki temu masz kontrolę nad wersjami i łatwo je aktualizujesz.
• Katalog `uploads` – To są media wgrywane przez klienta. Ten folder może ważyć gigabajty i nie ma nic wspólnego z kodem. Musi być synchronizowany między środowiskami w inny sposób.
• Plik `wp-config.php` – Zawiera wrażliwe dane dostępowe do bazy. Zamiast tego użyj biblioteki `dotenv`, aby wczytywać dane z pliku `.env`, który jest ignorowany przez Gita.

Traktuj swoje repozytorium jak przepis na ciasto, a nie jak gotowe ciasto z lukrem i posypką. Przepis (kod) jest w Git, a składniki (WordPress, wtyczki) i dekoracje (media, baza danych) są dodawane w trakcie „pieczenia” na każdym środowisku.

Święty Graal: Migracja Bazy Danych i Mediów

To jest moment, w którym większość ludzi się poddaje. Jak przenieść zmiany w bazie danych (np. nowe strony dodane przez klienta na produkcji) na środowisko deweloperskie bez nadpisywania swoich lokalnych ustawień? I jak synchronizować media?

Problem: Baza danych żyje własnym życiem

Baza danych na produkcji ciągle się zmienia – klienci dodają wpisy, użytkownicy się rejestrują, wpadają zamówienia w sklepie. Jednocześnie Ty na środowisku deweloperskim możesz zmieniać opcje w panelu, dodawać pola ACF itp. Proste zastąpienie bazy produkcyjnej deweloperską (lub odwrotnie) prowadzi do utraty danych.

Rozwiązaniem są narzędzia, które potrafią inteligentnie synchronizować i migrować dane.

• WP-CLI: To interfejs linii komend dla WordPressa. Narzędzie dla profesjonalistów. Komendy takie jak `wp db export` i `wp db import` to podstawa. Ale prawdziwa magia to `wp search-replace 'https://produkcja.pl’ 'https://dev.test’`, która inteligentnie podmienia adresy URL w bazie, naprawiając serializowane dane.
• Wtyczki do migracji: Narzędzia takie jak WP Migrate (w wersji darmowej lub Pro) czy All-in-One WP Migration automatyzują ten proces, oferując wygodny interfejs graficzny. Wersje Pro często pozwalają na migrację wybranych tabel, co jest niezwykle pomocne.
• Synchronizacja mediów: Katalog `uploads` najwygodniej synchronizować za pomocą `rsync` z linii komend lub przy użyciu wtyczek, które potrafią pobierać media z serwera produkcyjnego „w locie” (np. wtyczka „Tachyon”).

Automatyzacja, czyli Magia Deployu

OK, masz już wszystko poukładane. Kod w Git, oddzielne środowiska. Jak teraz wgrać zmiany z gałęzi `main` na serwer produkcyjny bez użycia FTP?

Odpowiedź brzmi: CI/CD (Continuous Integration / Continuous Deployment). To procesy, które automatycznie wdrażają Twój kod po każdej zmianie w repozytorium. Zapomnij o ręcznym wgrywaniu plików!

• Narzędzia: Możesz użyć platform takich jak GitHub Actions, GitLab CI, Buddy.works czy DeployBot. Konfigurujesz w nich „pipeline”, czyli serię kroków do wykonania.
• Przykładowy proces:
  1. Robisz `git push` do gałęzi `main`.
  2. GitHub Actions (lub inne narzędzie) wykrywa zmianę.
  3. Uruchamia skrypt, który loguje się na Twój serwer.
  4. Pobiera najnowszą wersję kodu z repozytorium.
  5. Instaluje zależności (`composer install`).
  6. Buduje assety, jeśli trzeba (`npm run build`).
  7. Przełącza symbolic link, aby nowa wersja stała się aktywna (zero-downtime deployment).
  8. Czyści cache.

Automatyzacja to Twoja polisa ubezpieczeniowa od ludzkich błędów. Komputer nie zapomni wgrać jakiegoś pliku ani nie pomyli serwerów. Raz skonfigurowany proces działa niezawodnie za każdym razem.

Podsumowanie: Workflow na miarę XXI wieku

Wdrożenie takiego workflow może na początku wydawać się skomplikowane, ale to inwestycja, która zwraca się wielokrotnie. Zyskujesz stabilność, bezpieczeństwo i szybkość pracy. Koniec ze stresem przy każdym wdrożeniu. Twój kod jest pod kontrolą, baza danych jest bezpieczna, a wdrożenia są przewidywalne i zautomatyzowane.

To właśnie podejście pozwala tworzyć solidne i skalowalne projekty WordPress. Jeśli ten temat Cię interesuje i szukasz kogoś, kto potrafi wdrożyć takie procesy w życie, zerknij na moje portfolio na michalzareba.pl i daj znać!