Profesjonalny workflow: staging, Git, wdrożenia i monitoring

Na stagingu wyłącz wysyłkę e-maili do klientów i płatności produkcyjne (tryb testowy bramki), a wersję zablokuj przed robotami i osobami postronnymi.

W repozytorium trzymaj kod: własny motyw, własne wtyczki, konfigurację. Nie wersjonuj wp-content/uploads, kopii bazy ani haseł.

• plik .gitignore dla uploadów, cache, node_modules i plików środowiskowych,
• sekrety w zmiennych środowiskowych lub poza repozytorium (wp-config.php poza Gitem),
• gałąź main = produkcja; zmiany w osobnych gałęziach i przez pull request z opisem,
• zależności PHP przez Composer, a front przez proces budowania (minifikacja, wersjonowanie plików),
• opisowe commity: „Naprawa CLS w nagłówku sklepu”, a nie „poprawki”.

Wdrożenie powinno być powtarzalne jednym poleceniem lub automatycznie po scaleniu gałęzi (np. GitHub Actions, GitLab CI, Deployer).

• pipeline: testy i linter → budowanie zasobów → kopia produkcji → wdrożenie → test dymny,
• bazę i adresy przenoś narzędziem WP-CLI, np. wp search-replace (obsługuje serializację danych),
• aktualizacje wtyczek najpierw na stagingu, potem — po teście kluczowych ścieżek — na produkcji,
• przygotuj plan wycofania: poprzednia wersja kodu i kopia bazy sprzed wdrożenia,
• wdrażaj na początku tygodnia i dnia — nie w piątek po południu.

O awarii powinieneś dowiedzieć się przed klientem.

• monitoring dostępności co 1–5 minut z powiadomieniem SMS / komunikator (np. UptimeRobot, Better Stack),
• monitoring ważności certyfikatu SSL i domeny,
• logi błędów PHP i JavaScriptu (np. Sentry) — z alertem przy skoku liczby błędów,
• kontrola kluczowych ścieżek: formularz kontaktowy i proces zakupu testuj regularnie (ręcznie lub testem automatycznym),
• cotygodniowy przegląd: aktualizacje, kopie, raport bezpieczeństwa, Core Web Vitals.

Dobra dokumentacja oszczędza godziny przy każdej zmianie wykonawcy i chroni klienta przed uzależnieniem od jednej osoby.

• README projektu: stack, wymagania, uruchomienie lokalne, proces wdrożenia,
• lista usług i dostępów (bez haseł — te w menedżerze haseł klienta),
• lista wtyczek z uzasadnieniem, dlaczego każda jest potrzebna,
• dziennik zmian (changelog) i decyzje architektoniczne,
• krótka instrukcja dla redaktorów: jak dodać wpis, zdjęcie, podstronę.

Standard Master Being: klient zawsze jest właścicielem domeny, hostingu, kodu i dostępów. To buduje zaufanie lepiej niż jakakolwiek umowa.