Środowisko testowe
Środowisko, w którym programista nie jest w stanie symulować i debugować oprogramowania tak, jak będzie ono uruchamiane w produkcji, oznacza, że nie może on również łatwo przetestować swoich rozwiązań.
To najgorsze środowisko, które mogę jedynie radzić opuścić jak najszybciej, najlepiej od razu. Jeżeli programista nie może po prostu uruchomić wprowadzanej zmiany i iterować na niej dość łatwo, to nie zajdzie daleko, jeśli nie zna rozwiązania na pamięć. Wszystkie etapy kompilacji, integracji i testowania na środowisku oddalonym o wiele kroków i kilkadziesiąt minut automatycznie zniechęcają i demotywują każdego programistę, który pracuje nad kodem, który powinien być sprawdzany od ręki.
Tutaj pojawia się najczęściej narastający problem związany bezpośrednio z wielkością systemów, które coraz trudniej jest uruchamiać na lokalnej maszynie. Programista wytwarza kod najczęściej na przeciętnej maszynie, ale nawet większe stacje robocze nie zawsze dysponują możliwością uruchomienia całego ekosystemu usług większego systemu – mimo najlepszego zastosowania kontenerów lub podobnych rozwiązań tego rodzaju bezpośrednio i całościowo na maszynie programisty.
Najczęściej właśnie z powodu powyższego ograniczenia programiści są zmuszeni testować zmiany dopiero po wydaniu ich na zewnętrzne środowiska testowe – najczęściej za pomocą jakiegoś mechanizmu ciągłej integracji (CI) lub ciągłego dostarczania (CD), przy czym możliwości debugowania lub śledzenia takiego wdrożenia są żadne. Takie rozwiązanie pozwala jedynie na walidowanie poprawności działania poprawnie działającego oprogramowania, a jednocześnie oddala programistę od możliwości bezpośredniego i bezzwłocznego testowania wprowadzanych zmian.
Takie typowe środowisko testowe odcięte od środowiska wytwarzania oprogramowania ogranicza możliwości debugowania kodu, szybkiego iterowania, eksplorowania i testowania wprowadzanych poprawek lub funkcjonalności.
Czy rozwiązaniem tego dylematu jest zatem wprowadzenie lepszych systemów ciągłego dostarczania i środowisk testowych tak, aby kompilować i wdrażać mniejsze fragmenty szybciej, czy może rozwiązaniem jest przeniesienie środowiska programistycznego bliżej środowiska testowego?