Staging: bezpieczne testowanie

Moduł 8: Kopie zapasowe, środowisko testowe (staging) i aktualizacje PHP · Czas czytania: 9 minut

Cel lekcji: Po tej lekcji będą Państwo potrafili utworzyć środowisko testowe (staging), zabezpieczyć je przed niepowołanym dostępem i bezpiecznie przenieść zmiany z powrotem na swoją rzeczywistą stronę.

Kluczowe pojęcia: staging, produkcja, klonowanie, subdomena, noindex, hasło na katalog, wyłączona poczta, dostawca płatności w trybie testowym, synchronizacja, nadpisanie bazy danych, lokalne środowisko programistyczne

Czym jest środowisko testowe (staging)

Środowisko testowe (staging) (lub strona testowa) to kopia Państwa rzeczywistej strony, pod własnym adresem, na której wypróbowują Państwo zmiany. Rzeczywista strona nazywana jest wtedy produkcją. Na stagingu coś może pójść źle: nowy motyw, duża aktualizacja, aktualizacja PHP (lekcja 8.4), nowa wtyczka. Dopiero gdy działa, wprowadzają Państwo zmianę na produkcji.

Staging warto wykorzystywać przy zmianach obarczonych ryzykiem: dużych wersjach WordPressa lub wtyczki sklepu internetowego, zmianie motywu, aktualizacji PHP, porządkowaniu wtyczek (lekcja 5.4), przeprojektowaniu strony. Przy zmianie tekstu lub drobnej aktualizacji wtyczki nie jest to konieczne.

Sposoby tworzenia środowiska testowego (staging)

Środowisko testowe na subdomenie (staging.example.com) jest zwykle lepsze niż w podkatalogu (example.com/staging): zachowuje się bardziej jak Państwa rzeczywista strona, a pliki cookie i reguły w .htaccess nie mieszają się ze sobą. Najpierw należy utworzyć subdomenę, wraz z certyfikatem.

Zabezpieczanie: trzy rzeczy, które warto od razu załatwić

Kopia strony jest pełnoprawną stroną ze wszystkimi Państwa treściami, a czasem również ze wszystkimi danymi klientów. Dlatego od razu warto zadbać o:

1. Odcięcie od wyszukiwarek

Bez zabezpieczenia Google może znaleźć i zindeksować Państwa środowisko testowe. Powstanie wtedy duplikat treści, a osoby szukające trafią na Państwa stronę testową. Proszę zastosować co najmniej jedno, najlepiej dwa z poniższych rozwiązań:

• Hasło na całe środowisko testowe (uwierzytelnianie podstawowe przez panel hostingowy, „zabezpieczony katalog”). Wtedy nikt nie zobaczy strony bez hasła, również wyszukiwarki. To najsilniejsze zabezpieczenie.
• Zniechęcenie wyszukiwarek w Ustawienia > Czytanie (lekcja 2.4). Ustawia to noindex na każdej stronie. Wyszukiwarki zwykle to respektują, ale jest to prośba, a nie blokada.

Proszę zwrócić uwagę na sytuację odwrotną: jeśli później synchronizują Państwo środowisko testowe z powrotem na produkcję, proszę nie przenosić zaznaczenia noindex. Strona produkcyjna, która po „udanej” synchronizacji znika z Google, to klasyczny błąd. Zadanie z tej lekcji sprawdza oba te elementy.

2. Brak poczty do prawdziwych osób

Kopia sklepu internetowego lub strony z kontami użytkowników może wysyłać pocztę: potwierdzenia, przypomnienia, newslettery, linki do resetowania hasła. Klienci otrzymują wtedy mylące wiadomości ze strony testowej. Proszę wyłączyć wychodzącą pocztę na stagingu lub przekierować ją na własny adres (za pomocą wtyczki przechwytującej pocztę, albo wyłączając wtyczkę SMTP na stagingu, lekcja 9.1). Proszę wyłączyć również zaplanowane zadania wysyłające pocztę.

3. Płatności i integracje w trybie testowym

Sklep internetowy na stagingu powinien działać w trybie testowym dostawcy płatności, a nie na prawdziwych płatnościach. Inne integracje (księgowość, magazyn, CRM) należy wyłączyć lub przełączyć na środowisko testowe, w przeciwnym razie potraktują testowe zamówienia jako prawdziwe.

Jeśli pracują Państwo z rzeczywistymi danymi klientów na stagingu, obowiązuje tam RODO na tych samych zasadach (lekcja 9.3): nie przechowywać dłużej niż to konieczne i usunąć środowisko testowe po zakończeniu pracy.

Powrót na produkcję: pułapka związana z bazą danych

Najtrudniejszym krokiem jest przeniesienie wprowadzonych zmian z powrotem na produkcję. Instalatory i wtyczki do stagingu mają do tego funkcję (w Installatron „Synch”, w innych „Push to live”). Ryzyko:

• W poniedziałek tworzą Państwo środowisko testowe. Od wtorku do czwartku testują Państwo nowy motyw.
• W międzyczasie na produkcji pojawia się dwadzieścia nowych zamówień, trzy nowe wpisy i pięćdziesiąt komentarzy.
• W piątek synchronizują Państwo bazę danych ze stagingu na produkcję. Baza danych stagingu pochodzi z poniedziałku: zamówienia, wpisy i komentarze z okresu od wtorku do piątku znikają.

Dlatego:

1. Proszę najpierw utworzyć kopię zapasową produkcji (lekcja 8.1), tuż przed synchronizacją.
2. Proszę synchronizować tylko to, co konieczne. Aktualizacja motywu lub wtyczki to kwestia plików; baza danych często nie musi być przy tym przenoszona. Wiele funkcji synchronizacji pozwala wybrać: tylko pliki albo tylko określone tabele.
3. W przypadku sklepu internetowego lub ruchliwej strony: lepiej wprowadzić zmianę ponownie bezpośrednio na produkcji (te same kroki, które wykonano na stagingu, skoro już wiadomo, że działają) niż przenosić bazę danych. Albo zaplanować spokojny moment z krótkim zatrzymaniem sklepu.
4. Następnie proszę sprawdzić produkcję: listę kontrolną z lekcji 8.2 oraz zaznaczenie noindex.

Staging to miejsce, w którym można nauczyć się, co się dzieje. Samą zmianę najbezpieczniej jest wykonać ponownie bezpośrednio na produkcji.

Porządkowanie

Środowisko testowe, które pozostaje aktywne przez miesiące, staje się zapomnianą stroną: nieaktualizowaną, ze starymi wtyczkami i prawdziwymi danymi. Dokładnie tym słabym punktem, o którym mowa w lekcji 7.1. Proszę usunąć środowisko testowe po zakończeniu pracy albo utrzymywać je jak pełnoprawną stronę (aktualizacje, hasło). Klon zajmuje tyle samo miejsca co oryginał i ma własną bazę danych.

Podsumowanie

• Staging to kopia strony pod własnym adresem służąca do testowania ryzykownych zmian.
• Proszę utworzyć je za pomocą instalatora, dostawcy hostingu, wtyczki lub ręcznie, najlepiej na subdomenie z certyfikatem.
• Proszę od razu je zabezpieczyć: hasłem i/lub noindex, bez wysyłania poczty do prawdziwych osób, z płatnościami w trybie testowym.
• Proszę nie synchronizować z powrotem bezrefleksyjnie: baza danych stagingu nadpisze to, co pojawiło się na produkcji. Najpierw kopia zapasowa, synchronizacja tylko tego, co konieczne, albo ponowne wykonanie zmiany.
• Proszę usunąć środowisko testowe po zakończeniu pracy i nie przenosić zaznaczenia noindex na produkcję.

Quiz

Zadanie

Zadanie A8.3: Czy środowisko testowe (staging) jest zabezpieczone? Proszę wpisać adres swojego środowiska testowego (subdomena własnej domeny, na przykład z zadania D8.2) oraz adres swojej rzeczywistej strony. Proszę udowodnić za pomocą kodu z zadania, że domena należy do Państwa. Program sprawdzi na stronie testowej: czy odpowiada przez https i czy jest zabezpieczona (pytanie o hasło albo noindex w kodzie HTML lub w nagłówku X-Robots-Tag)? Czy odnośnik REST (wp-json) wskazuje na sam staging, a nie na Państwa rzeczywistą stronę? A na Państwa rzeczywistej stronie: czy nie ma tam noindex?

Dalsza lektura

Te artykuły opisują kroki w panelach WebOké; w innych panelach działają one w podobny sposób.

• Instrukcja DirectAdmin 13.7: Klonowanie i tworzenie środowiska testowego (staging)
• Tworzenie środowiska testowego (staging) WordPress
• Instrukcja DirectAdmin 15.9: Katalogi chronione hasłem
• Instrukcja DirectAdmin 4.5: Tworzenie i usuwanie subdomen
• Instrukcja DirectAdmin 13.8: Usuwanie instalacji