Środowisko testowe przed publikacją.

DefinicjaŚrodowisko testowe, po angielsku staging, to osobna kopia strony albo aplikacji, ustawiona możliwie tak samo jak wersja dla klientów, ale pod innym adresem i ukryta przed wyszukiwarkami. Programista publikuje na niej zmiany, a właściciel projektu sprawdza je i akceptuje, zanim trafią na produkcję, czyli stronę, którą widzą wszyscy.

Czym jest środowisko testowe?

To druga, osobna kopia Twojej strony albo aplikacji, ukryta przed klientami i wyszukiwarkami. Działa pod innym adresem, np. test.twojafirma.pl, i służy do sprawdzania zmian, zanim trafią do wersji, którą widzą wszyscy.

W branży mówi się na nią staging; angielskie słowo oznacza przygotowanie do wystawienia, coś jak próbę generalną przed premierą. Wersja dla klientów to produkcja. Dobre środowisko testowe jest ustawione możliwie tak samo jak produkcja: ten sam system, te same wtyczki, podobny serwer. Dzięki temu to, co działa na teście, najpewniej zadziała też na żywo.

Jak zmiana trafia z komputera programisty na stronę?

Zwykle przechodzi przez trzy miejsca: komputer programisty, środowisko testowe i produkcję. Na każdym etapie ktoś inny ją ogląda, więc błąd ma kilka okazji, żeby zostać złapany, zanim zobaczy go klient.

1. Lokalnie, czyli na komputerze programisty. Tu powstaje zmiana i tu programista sprawdza ją pierwszy raz. Nikt poza nim jej nie widzi.
2. Środowisko testowe. Programista publikuje zmianę pod adresem testowym. Ty klikasz, porównujesz z ustaleniami i zgłaszasz uwagi albo akceptujesz.
3. Produkcja. Dopiero zaakceptowana wersja trafia pod właściwy adres, do Twoich klientów.

Każdy etap korzysta z tej samej historii zmian w kodzie, o której piszę w artykule Kontrola wersji po ludzku. Przenoszenie zmian między etapami da się zautomatyzować (tzw. CI/CD, czyli automatyczne sprawdzanie i publikowanie zmian), ale to temat na osobny artykuł.

Co daje mi środowisko testowe?

Przede wszystkim to, że zmiany pierwszy oglądasz Ty, a nie Twoi klienci. Na żywej stronie każdy błąd jest publiczny; na stagingu jest tylko punktem na liście poprawek.

• Akceptacja przed publikacją: sprawdzasz nową podstronę, cennik czy funkcję w aplikacji i decydujesz, kiedy idzie na żywo. Takie sprawdzenie to test akceptacyjny; pozostałe rodzaje testów opisuję w artykule Testy oprogramowania.
• Bezpieczne testy formularzy i płatności: możesz wysłać zapytanie, złożyć zamówienie i zapłacić, nie zaśmiecając skrzynki zespołu i nie obciążając niczyjej karty.
• Aktualizacje bez nerwów: nową wersję WordPressa albo wtyczki instaluje się najpierw na kopii. Jeśli coś się rozjedzie, naprawia się to spokojnie, a produkcja działa dalej. Więcej o aktualizacjach w artykule Opieka nad stroną po wdrożeniu.
• Treści gotowe przed startem: teksty, zdjęcia i produkty wprowadzasz do nowej strony, zanim ktokolwiek ją zobaczy. W dniu startu wszystko jest już na miejscu.
• Nowa strona obok starej: przy przebudowie obecna strona działa do dnia przełączenia, a nową oglądasz pod adresem testowym. Jak przy tym zadbać o Google, piszę w artykule o odświeżeniu strony bez utraty pozycji.

Jak ukryć wersję testową przed Google?

Najpewniej hasłem: przeglądarka prosi o login i hasło, zanim cokolwiek pokaże, więc ani wyszukiwarka, ani przypadkowa osoba nie zobaczy strony. Google w swojej dokumentacji wskazuje ochronę hasłem jako sposób na treści, które mają oglądać tylko uprawnione osoby.

Drugi sposób to noindex, czyli informacja w kodzie strony: „nie pokazuj mnie w wynikach wyszukiwania”. Częsty błąd to poleganie na samym pliku robots.txt, czyli liście adresów, które roboty wyszukiwarek mają omijać. Według Google adres zablokowany w robots.txt może i tak trafić do wyników, jeśli ktoś do niego linkuje, a noindex działa tylko wtedy, gdy robot może wejść na stronę i go przeczytać.

Po co ta ostrożność? Klient, który trafi z Google na wersję testową, może zostawić tam zapytanie, które nigdzie nie dojdzie. Przy przenoszeniu zmian na produkcję trzeba też pilnować, żeby blokada nie przeszła razem z nimi: noindex skopiowany na żywą stronę sprawi, że zniknie z Google prawdziwa strona.

Czy na stagingu mogą być dane moich klientów?

Lepiej nie. Wersja testowa często ma więcej osób z dostępem i częściej się zmienia niż produkcja, więc prawdziwe dane klientów to tam niepotrzebne ryzyko, także w świetle RODO.

Zamiast nich używa się danych testowych: wymyślonych klientów, zamówień i adresów. Gdy do znalezienia błędu potrzebna jest kopia prawdziwej bazy, dane osobowe podmienia się na fikcyjne, zanim trafią na test.

Tak samo z pieniędzmi i wiadomościami. Operatorzy płatności zwykle mają tryb testowy (tzw. sandbox, czyli piaskownicę): płatność przechodzi całą ścieżkę, ale nikt nie zostaje obciążony. E-maile ze stagingu powinny trafiać do skrzynki testowej albo tylko do zespołu, żeby żaden klient nie dostał potwierdzenia zamówienia, którego nie składał. Dobrze też, żeby wersja testowa miała u góry wyraźny pasek „wersja testowa”. Wtedy nikt jej nie pomyli z żywą stroną.

Ile kosztuje środowisko testowe?

Tyle, ile druga kopia strony na serwerze i czas na jej utrzymanie. Dokładna kwota zależy od projektu, dlatego ustala się ją przy wycenie, a nie z góry.

• Miejsce na serwerze: staging potrzebuje hostingu, często tego samego co produkcja, tylko pod osobnym adresem. Przy aplikacjach bywa to osobny serwer i osobna baza danych.
• Czas programisty: kopię trzeba założyć, zabezpieczyć i co jakiś czas odświeżyć, żeby nie odstawała od produkcji.
• Usługi zewnętrzne: płatności, wysyłka e-maili czy mapy potrzebują osobnych, testowych ustawień.

Warto to zestawić z kosztem błędu na żywej stronie: formularza, który przestał wysyłać zapytania, zablokowanego koszyka albo wieczoru spędzonego na ratowaniu strony po nieudanej aktualizacji.

Kiedy środowisko testowe jest zbędne?

Przy małej, prostej stronie, która zmienia się kilka razy w roku. Jeśli nie ma na niej płatności, logowania ani wtyczek, a zmiana to nowy tekst albo zdjęcie, stały staging bywa przesadą.

Wtedy zwykle wystarczy podgląd: programista pokazuje Ci zmianę pod tymczasowym adresem albo na zrzucie ekranu, a po akceptacji ją publikuje. Tak bywa szczególnie przy stronie statycznej, bez systemu i wtyczek do aktualizowania; różnice opisuję w artykule Strona statyczna czy WordPress?. Nowa strona i tak powinna jednak powstawać pod adresem testowym do dnia startu. Sklep, aplikacja z kontami użytkowników czy strona z płatnościami potrzebują stałego stagingu.