Środowiska podglądu w praktyce: świeża kopia aplikacji dla każdego pull requesta

Środowisko podglądu (preview environment) to tymczasowa kopia Twojej aplikacji, zbudowana z pull requesta lub gałęzi i działająca pod własnym adresem URL. Osoby sprawdzające zmianę otwierają link i oglądają ją w przeglądarce, zamiast czytać diff. Gdy praca jest skończona, środowisko znika.

Ten poradnik wyjaśnia, do czego przydają się środowiska podglądu, co sprawia, że ich utrzymanie bywa trudne, i jak działają na Nodion.

Czym jest środowisko podglądu?

Pomyśl o nim jak o tymczasowym środowisku stagingowym dla jednej zmiany. Każdy pull request albo wybrana przez Ciebie gałąź dostaje:

• własny build kodu z tej gałęzi,
• własną działającą aplikację z własnym adresem URL,
• własne kopie usług, od których zależy, zwykle co najmniej świeżą bazę danych,
• ograniczony czas życia.

Różnica w porównaniu z klasycznym, współdzielonym serwerem stagingowym: nikt nie czeka, aż staging się zwolni, a jedna niedokończona funkcja nie zepsuje testów innej. Ten sam pomysł spotkasz też pod nazwami review apps, deploy previews czy ephemeral environments.

Dlaczego zespoły z nich korzystają

• Ocena działającej aplikacji, nie tylko kodu. Rozjechany układ, niejasny przebieg działania albo wolna strona od razu rzucają się w oczy w przeglądarce, a w diffie łatwo je przeoczyć.
• QA dla każdej zmiany. Testerzy sprawdzają jedną zmianę w izolacji, zanim trafi do głównej gałęzi, więc każdy znaleziony błąd należy do dokładnie jednego pull requesta.
• Wgląd bez środowiska deweloperskiego. Projektanci, product managerowie czy klient po prostu otwierają link. Nie potrzebują lokalnej kopii repozytorium ani udostępniania ekranu.
• Testowanie migracji. Migracja schematu musi przejść na prawdziwej bazie danych, zanim środowisko podglądu zacznie działać. Migracja, która działa tylko na jednym laptopie, zawiedzie tutaj, a nie na produkcji.
• Praca równoległa. Pięć otwartych pull requestów to pięć środowisk podglądu zamiast kolejki do jednego serwera stagingowego.

Co sprawia trudność

Zbudowanie aplikacji to ta łatwa część. Trudne jest wszystko dookoła.

Bazy danych

Aplikację bez danych trudno ocenić, więc większość środowisk podglądu potrzebuje bazy danych. Są trzy typowe opcje: pusta baza, pusta baza z danymi startowymi (seed) albo kopia produkcji. Kopiowanie produkcji kusi, ale umieszcza prawdziwe dane klientów, w tym dane osobowe, w wielu krótkotrwałych środowiskach, do których dostęp ma więcej osób. Przy dużej bazie jest też powolne. Dla większości zespołów bezpieczniejszym domyślnym wyborem jest pusta baza ze skryptem seed, który tworzy realistyczne dane demonstracyjne.

Sekrety

Środowisko podglądu uruchamia kod, który nie przeszedł jeszcze review. Dane uwierzytelniające z produkcji nie mają tam czego szukać. Daj środowiskom podglądu klucze testowe lub sandboxowe do operatorów płatności, e-maili i zewnętrznych API, aby błąd w gałęzi nie mógł obciążyć prawdziwej karty ani wysłać e-maila do prawdziwych klientów.

Adresy URL i callbacki

Każde środowisko podglądu ma inną nazwę hosta. Adresy przekierowań OAuth, endpointy webhooków, reguły CORS i ciasteczka powiązane z Twoją domeną produkcyjną mogą przestać działać. Aplikacje, które odczytują swój bazowy URL z konfiguracji, zamiast mieć domenę produkcyjną wpisaną na sztywno, mają tu znacznie mniej problemów.

Koszty i sprzątanie

Każde otwarte środowisko podglądu uruchamia aplikację, a do tego nową bazę danych dla każdej bazy podłączonej do aplikacji nadrzędnej. Dziesięć otwartych pull requestów może oznaczać dziesięć dodatkowych środowisk, a zapomniane środowisko podglądu działa, dopóki ktoś go nie zamknie. Dlatego środowiska podglądu powinny wygasać automatycznie.

Jak działają środowiska podglądu na Nodion

Na Nodion środowiska podglądu są częścią każdej aplikacji wdrażanej z repozytorium Git:

• Włącz je w sekcji Settings aplikacji.
• Jedno środowisko podglądu na pull request lub gałąź. Każde z nich to tymczasowa aplikacja z własnym adresem URL.
• Ręcznie lub automatycznie. Utwórz środowisko podglądu ręcznie albo pozwól, by Nodion tworzył je automatycznie dla pull requestów.
• Świeża baza danych. Dla każdej bazy danych podłączonej do aplikacji środowisko podglądu dostaje własną, pustą bazę, nigdy klon Twoich danych produkcyjnych. Wolumeny, buckety i strefy e-mail nie są kopiowane.
• Ustawienia aplikacji są przenoszone. Środowisko podglądu startuje z kopią zmiennych środowiskowych aplikacji, łącznie z sekretami. Zmienne podłączonych baz danych wskazują na świeże bazy środowiska podglądu; wszystko inne, w tym klucze i adresy URL innych usług, jest kopiowane bez zmian, więc to sprawdź. Nodion dodaje NODION_PREVIEW=1, NODION_PR_NUMBER, NODION_BRANCH i NODION_PARENT_APP.
• Środowiska podglądu wygasają po określonej liczbie dni bez wdrożenia (domyślnie po 7 dniach; możesz to zmienić w ustawieniach aplikacji). Do tego czasu każde z nich możesz ponownie wdrożyć lub zamknąć w zakładce Previews aplikacji.
• Tylko aplikacje z Git. Aplikacje wdrażane z gotowego obrazu nie mają środowisk podglądu.

Nowa baza danych to świadomy wybór: bazy podłączone do środowisk podglądu startują puste, więc nie zawierają danych produkcyjnych. Sprawdź też skopiowane klucze i adresy URL, aby kod w środowisku podglądu nie mógł przez nie uzyskać dostępu do systemów produkcyjnych. Twoja aplikacja musi umieć wystartować z pustą bazą, co i tak warto dopracować.

Na początek połącz repozytorium w integracjach Git, utwórz z niego aplikację i włącz środowiska podglądu w jej ustawieniach. Szczegóły znajdziesz w dokumentacji aplikacji.

Typowy cykl review

1. Deweloper otwiera pull request. Gdy automatyczne środowiska podglądu są włączone, startuje dla niego środowisko podglądu z własnym adresem URL i pustą bazą danych.
2. Deweloper wkleja link do środowiska podglądu w pull requeście. Osoby oceniające zmianę, testerzy QA i właściciel produktu otwierają środowisko w przeglądarce.
3. Po uwagach powstają nowe commity. Wdróż ponownie środowisko podglądu z zakładki Previews, aby osoby sprawdzające zmianę zobaczyły najnowszy kod.
4. Gdy zmiana zostanie zatwierdzona i scalona, zamknij środowisko podglądu albo pozwól mu wygasnąć automatycznie.

Nikt nie musiał czekać na zwolnienie stagingu, a Nodion utworzył nową bazę zamiast korzystać z produkcyjnej. Przed uruchomieniem kodu w środowisku podglądu sprawdź wszystkie pozostałe skopiowane klucze i adresy URL, bo nadal wskazują tam, gdzie wskazują ustawienia aplikacji.

Przygotuj aplikację na środowiska podglądu

• Uruchamiaj migracje automatycznie przy wdrożeniu lub starcie aplikacji, aby świeża baza danych dostała aktualny schemat bez ręcznych kroków.
• Dodaj skrypt seed, który tworzy testowe konto i trochę treści demonstracyjnych. Osoby sprawdzające zmianę powinny zobaczyć coś przydatnego już po pierwszym kliknięciu.
• Odczytuj bazowy URL ze zmiennej środowiskowej, zamiast wpisywać na sztywno domenę produkcyjną.
• Przełącz efekty uboczne w tryb testowy, gdy ustawiona jest zmienna NODION_PREVIEW: płatności, e-maile i wszystko, co zapisuje dane w innych systemach. Środowiska podglądu dziedziczą sekrety aplikacji, więc bez tego sprawdzenia środowisko podglądu użyje Twoich kluczy produkcyjnych.
• Utrzymuj małe pull requesty. Środowisko podglądu dla jednej, konkretnej zmiany jest dużo łatwiejsze do oceny niż środowisko dla tygodnia pracy.

Kiedy możesz z nich zrezygnować

Przy projekcie prowadzonym w pojedynkę i kilku zmianach w tygodniu może wystarczyć lokalna konfiguracja i produkcja. Środowiska podglądu zaczynają się opłacać, gdy zmiany przegląda, testuje lub zatwierdza więcej niż jedna osoba albo gdy migracje bazy danych są stałą częścią Twojej pracy.

Środowiska podglądu są dostępne w każdej aplikacji z Git na Nodion, razem z procesami, logami, metrykami i automatycznym wdrażaniem (auto-deploy). Pełny obraz znajdziesz na stronie Aplikacje.