W dzisiejszym dynamicznym świecie technologii oprogramowania, tworzenie oraz utrzymanie wysokiej jakości aplikacji i systemu jest kluczową kwestią dla firm. W tym celu niezbędne jest posiadanie różnych rodzajów środowisk nieprodukcyjnych, które umożliwią deweloperom, testerom i innym specjalistom, pracę nad aplikacjami w bezpiecznym i kontrolowanym otoczeniu.
W procesie wytwarzania oprogramowania pojęcie środowisko odnosi się do zestawu narzędzi, technologii, platform i zasobów, w tym danych testowych, które wykorzystuje się podczas tworzenia, testowania oraz wdrażania nowego oprogramowania.
Środowisko, na które w ostatniej fazie wytwarzania zostaje wdrożone oprogramowanie, a użytkownik końcowy ma do niego dostęp, nazywane jest środowiskiem produkcyjnym. Oprócz oprogramowania obejmuje ono także infrastrukturę sprzętową, serwery, może także obejmować sieć, bazy danych oraz elementy potrzebne do działania oprogramowania na produkcji.
Środowisko nieprodukcyjne w obszarze IT jest zaprojektowane do eksperymentowania, rozwijania i testowania nowych funkcji, poprawiania błędów, sprawdzania i optymalizacji wydajności oraz prowadzenia szkoleń dla użytkowników, bez zbędnego narażania środowiska produkcyjnego na ryzyko. W zależności od celu prowadzonych działań, można wyodrębnić następujące typy środowisk: środowisko deweloperskie, środowisko testowe, środowisko szkoleniowe, środowisko do testów wydajnościowych, itp.
Na kolejnych etapach procesu wytwórczego można spotkać środowiska o zróżnicowanym charakterze w zależności od kontekstu projektu. Kluczowe jest określenie w jakim celu i dla kogo dane środowisko powstaje.
W tym artykule przyjrzymy się różnym typom środowisk nieprodukcyjnych, aby lepiej zrozumieć ich znaczenie i zastosowanie.
Charakterystyka środowisk nieprodukcyjnych
Środowiska nieprodukcyjne możemy opisywać poprzez szereg cech, które pomagają w realizacji zadań testowych czy rozwoju oprogramowania.
- Izolacja – oddzielenie środowisk nieprodukcyjnych od środowiska produkcyjnego zapewnia, że przeprowadzane testy, eksperymenty czy nawet szkolenia nie wpływają na funkcjonowanie rzeczywistych użytkowników i systemu produkcyjnego. To pomaga także zminimalizować ryzyko wprowadzenia błędów czy niechcianych zmian na środowisko produkcyjne.
- Elastyczność – środowiska powinny być projektowane w sposób elastyczny, aby w łatwy i szybki sposób umożliwić skonfigurowanie i dostosowanie środowiska do różnych wymagań, potrzeb testów, w tym specyficznych scenariuszy testowych.
- Zarządzanie danymi – istotne jest zarządzanie danymi testowymi w środowiskach nieprodukcyjnych. W zależności od kontekstu oprogramowania, dane te mogą być łatwe do pozyskania lub trudne i wymagać specyficznych przygotowań, w tym symulatorów. Można stosować dane testowe, dane sztucznie wygenerowane lub dane produkcyjne. Wykorzystując dane produkcyjne należy pamiętać o zasadach RODO. Dlatego zamiast pracować na rzeczywistych danych warto je zanonimizować np. używając do tego narzędzia Soflab G.A.L.L. Użycie danych rzeczywistych zanonimizowanych pozwala wykonać testy, na danych, które zachowują się jak produkcyjne, ale nie są prawdziwymi danymi klientów. Oznacza to, że takie dane posiadają m. in. historię transakcji, są ze sobą powiązane, a po anonimizacji zachowują spójność i wiarygodność w ujęciu technicznym (relacje między danymi przechowywanymi w różnych bazach) i merytorycznym (biznesowym).
- Adekwatność – środowisko powinno być adekwatne do celu stawianego przeprowadzanym na nim testom lub wykonywanym zadaniom. Na przykład na środowisku deweloperskim czy testowym nie musimy mieć w pełni odwzorowanego środowiska produkcyjnego, by wykonane testy były miarodajne. Natomiast środowisko szkoleniowe nie musi zawierać pełnej infrastruktury, może mieć część systemów zaślepionych, by np. przeprowadzić warsztaty szkoleniowe z aplikacji dla nowych użytkowników.
- Wersjonowanie – oprogramowanie na środowiskach nieprodukcyjnych powinno być zarządzane za pomocą systemów kontroli wersji, aby umożliwić śledzenie zmian, łatwiejsze zarządzanie kodem i replikację środowiska na różnych etapach projektu.
- Kontrola – środowisko nieprodukcyjne powinno być ściśle zarządzane, w kontekście zarządzania dostępem i kontrolowania zmian. Ograniczenie dostępu do środowisk nieprodukcyjnych ma zapewnić bezpieczeństwo danych, aplikacji i uniknąć niepożądanych wpływów wprowadzanych zmian na produkcję.
- Powtarzalność – środowiska nieprodukcyjne powinny być łatwe w powielaniu, umożliwiając powtarzalność testów i eksperymentów. Powielanie środowisk testowych stosuje się w celu uzyskania odrębnych środowisk do różnych rodzajów testów, np. do testów wydajności, migracji danych, czy integracji. Testowanie tego na jednym środowisku testowym mogłoby ograniczyć lub uniemożliwić przeprowadzenie innych testów, np. funkcjonalnych czy automatycznych.
Jakie są rodzaje środowisk nieprodukcyjnych?
Ze środowisk, które nie służą do celów produkcyjnych, możemy wyodrębnić te, które wspierają proces wytwórczy oprogramowania. Podstawowe typy takich środowisk zostały opisane poniżej.
Środowisko deweloperskie – środowisko to jest przeznaczone przede wszystkim dla programistów do tworzenia, modyfikowania i sprawdzania jak działa w praktyce ich kod. Zapewnia dostęp do narzędzi programistycznych, bibliotek, debuggerów i innych zasobów potrzebnych do efektywnej pracy. Środowisko deweloperskie jest zwykle elastyczne, pozwala programistom eksperymentować z różnymi rozwiązaniami, umożliwia iteracyjny rozwój systemu, jest zazwyczaj niezależne od innych środowisk, co umożliwia pracę w izolacji. Środowiska te wykorzystują często narzędzia do kontroli wersji, np. Git, umożliwiające zarządzanie kodem źródłowym i współpracę zespołową. Często każdy programista posiada lokalną wersję aktualnego kodu.
Środowisko testowe – środowisko, w skład którego wchodzi sprzęt, wyposażenie, symulatory, narzędzia programowe oraz inne elementy wspierające, potrzebne do wykonania testu [ISO/IEC/IEEE 24765]. Służy do testowania i weryfikacji systemu przed wdrożeniem zmian na środowisko produkcyjne. Może istnieć wiele środowisk testowych, na przykład środowisko testowania wydajności, środowisko testów integracyjnych, środowisko testów bezpieczeństwa oraz środowisko testowania przedprodukcyjnego. Zastosowanie odrębnych środowisk do różnych rodzajów testów pozwala ograniczyć wzajemny wpływ jednych testów na inne, np. testy wydajnościowe mogłyby uniemożliwić jednoczesne przeprowadzenie testów funkcjonalnych, bądź bezpieczeństwa. Środowisko testowe powinno być bardziej stabilne, dopracowane i wydajne niż środowisko deweloperskie. Środowiska testowe pomagają wykrywać błędy i niedoskonałości aplikacji przed jej udostępnieniem użytkownikom. W tym środowisku testerzy mogą symulować różne scenariusze i warunki, aby upewnić się, że aplikacja działa zgodnie z oczekiwaniami. W środowisku testowym istnieje większa elastyczność w zarządzaniu danymi testowymi. Zaleca się stosowanie danych wygenerowanych specjalnie do celów testowych, które można łatwo modyfikować, co ułatwia przeprowadzanie różnych scenariuszy testowych i manipulację danymi. Stosowanie danych produkcyjnych może ograniczać tę elastyczność i utrudniać przeprowadzenie testów o różnych przypadkach użycia. Na tym etapie warto posiłkować się danymi testowymi jak najbardziej zbliżonymi do rzeczywistych, jednak należy zadbać, aby nie były to dane prosto z produkcji. Podczas pracy na danych produkcyjnych w środowisku testowym może dojść do wycieku danych wrażliwych. Organizacje przetwarzające te dane mają prawny obowiązek zapewnić im pełne bezpieczeństwo. Dane należy dostosować do potrzeb testów i zapewnić ich odpowiednie zabezpieczenie, poprzez anonimizację lub maskowanie danych osobowych. Soflab G.A.L.L. anonimizuje dane produkcyjne i tym samym nie opuszczają one środowiska produkcyjnego. Nawet jeśli nastąpi wyciek danych ze środowiska testowego, to nie będą to dane wrażliwe. Dzięki temu można przeprowadzać testy skutecznie, zgodnie z obowiązującymi przepisami dotyczącymi prywatności, bezpieczeństwa danych i politykami firmy, na danych zachowujących się jak produkcyjne, np. ze spójną historią transakcji.
Środowisko preprodukcji (preprod) – środowisko to jest zbliżone do środowiska produkcyjnego pod względem konfiguracji i infrastruktury. Ma na celu sprawdzenie aplikacji (systemu) w rzeczywistych warunkach, aby upewnić się, że wszystko działa prawidłowo przed wypuszczeniem jej na rynek. Przy dużych systemach często dopiero na tym etapie weryfikuje się procedurę aktualizacji oprogramowania. Pozwala to na identyfikację i rozwiązanie ewentualnych problemów, które mogłyby mieć wpływ na działanie aplikacji w środowisku produkcyjnym, minimalizuje ryzyko błędów wdrożenia. Dobrą praktyką jest przeprowadzanie testów regresji zarówno po przygotowaniu nowej funkcyjności jak i poprawek do błędów produkcyjnych. Środowisko preprod jest zazwyczaj w pełni funkcjonalne i korzysta z danych zbliżonych do rzeczywistych, ale nie jest jeszcze dostępne publicznie. Na tym środowisku również warto zadbać o bezpieczeństwo danych stosowanych do testów. Zaleca się stosowanie danych wygenerowanych specjalnie do celów testowych. Można je dostosować do potrzeb testów oraz zapewnić odpowiednie zabezpieczenia danych, takie jak anonimizacja lub maskowanie danych osobowych. W środowisku przedprodukcyjnym można przeprowadzić testy ostateczne, sprawdzić wydajność, skalowalność.
Środowiska nieprodukcyjne mogą mieć zastosowanie także poza procesem wytwórczym oprogramowania. Do takich środowisk możemy zaliczyć szkoleniowe bądź disaster recovery, które jest w gotowości zastąpić środowisko produkcyjne w przypadku jego awarii.
Środowisko szkoleniowe – jest wykorzystywane do szkolenia pracowników lub osób zewnętrznych w zakresie korzystania z aplikacji lub nowych funkcji systemu. Środowisko szkoleniowe to środowisko, w którym można uczyć się, eksperymentować i testować różne scenariusze bez wpływu na środowisko produkcyjne. Może zawierać demo, scenariusze szkoleniowe, dane testowe, dokumentację i inne narzędzia ułatwiające proces szkolenia. Realizując scenariusz szkoleniowy, należy zastosować zanonimizowane dane maksymalnie zbliżone do danych rzeczywistych, które pozwalają na przeprowadzenie szkolenia. Pozwoli to na zapewnienie bezpieczeństwa danych produkcyjnych, przy jednoczesnym zachowaniu spójności danych w ramach procesu.
Środowisko disaster recovery – środowisko awaryjne jest tworzone w celu zapewnienia kontynuacji działania aplikacji, systemów informatycznych w przypadku awarii, katastrofy w środowisku produkcyjnym, po wystąpieniu nieprzewidzianych zdarzeń, takich jak awaria sprzętu, atak hakerski, zalanie, pożar, itp. Zaleca się, aby po zaistnieniu wymienionych sytuacji na środowisku produkcyjnym, automatycznie uruchomiła się procedura z włączeniem do sieci środowiska disaster recovery, tak by nie miało to znacznego wpływu na użytkowników. To środowisko jest odtwarzane na oddzielnej infrastrukturze, aby zapewnić ciągłość działania biznesu oraz minimalizować straty i czas przestoju. Zapewnia redundancję oraz odtwarzalność aplikacji i danych w przypadku awarii, utraty środowiska produkcyjnego lub utraty danych produkcyjnych. Środowisko disaster recovery jest zazwyczaj ustawiane w oddzielnej lokalizacji geograficznej, na odległych serwerach lub w chmurze i regularnie aktualizowane danymi z głównego środowiska produkcyjnego.
Środowiska nieprodukcyjne to nieodłączny element procesu wytwarzania i utrzymania aplikacji
Środowiska nieprodukcyjne są nieodłącznym elementem procesu wytwarzania i utrzymania aplikacji w dziedzinie IT. Każde z tych środowisk ma swoje własne cechy i cele, które przyczyniają się do zapewnienia jakości, bezpieczeństwa i wydajności aplikacji. Ważne jest zrozumienie różnic między tymi środowiskami i zapewnienie, że każde z nich jest odpowiednio skonfigurowane i zarządzane. Dzięki temu zespoły deweloperskie, testowe i inne mogą efektywnie pracować nad tworzeniem, testowaniem i utrzymaniem wysokiej jakości aplikacji. Przy odpowiednim wykorzystaniu, środowiska nieprodukcyjne pomagają zminimalizować ryzyko błędów i awarii, pozwalają usprawnić proces i zwiększyć skuteczność wytwarzania oprogramowania, a tym samym dostarczyć optymalne rozwiązania IT o wysokiej jakości.
