Pewny rozwój bez prawdziwego środowiska programistycznego

12

Niedawno zostałem zatrudniony do projektu obejmującego pracę z kilkoma systemami „korporacyjnymi” innych firm i wokół nich. Ze względu na to, co według mnie byłoby astronomicznym kosztem i wysiłkiem wymaganym do zbudowania wystarczająco wiernej repliki środowiska produkcyjnego, perspektywa posiadania prawdziwego środowiska programistycznego wydaje się znikoma.

To oczywiście nie jest idealne. Z drugiej strony, wyobrażam sobie, że muszą istnieć ludzie, którzy bezpiecznie testują i wdrażają oprogramowanie w takich niewiarygodnych środowiskach, i prawdopodobnie mogę pójść w ich ślady.

Jak robią to ci, którzy skutecznie radzą sobie z tego rodzaju sytuacjami?

testing development-process

— Jason Swett
źródło

1

Wirtualizacja, środowisko „podobne do” itp. Zasadniczo, spróbuj odtworzyć to, co możesz, na mniejszą skalę, aby pokryć przynajmniej większość „ruchomych części” systemu.

— Oded

6

Musisz polegać na poprawności interfejsu API systemu korporacyjnego i przeprowadzić wiele testów integracji, być może z niektórymi kontami testowymi.

— Robert Harvey

@RobertHarvey nie żyje tutaj. Ktoś powinien to wyjaśnić w odpowiedzi, ale właśnie tego potrzebujesz. W przypadku braku środowiska do ręcznego testowania systemu wszystko, co możesz zrobić, to automatycznie przetestować kod.

— Jimmy Hoffa

1

Ok, więc może dobrym pomysłem na wynos jest to, że jeśli nie możesz mieć pełnego środowiska programistycznego, konta testowe w produkcji mogą być kolejną najlepszą rzeczą.

— Jason Swett

9

Tak dzieje się cały czas w prawdziwym świecie. Znam faceta, który pisze aplikacje, które kontrolują gigantyczne szklarnie rolnicze - wentylacja, ogrzewanie, kontrola wilgoci. Nie ma „testowej szklarni”, ale ma program symulacyjny dostarczony przez firmę, który buduje rzeczywiste systemy sprzętowe. Jeśli kod działa poprawnie z symulatorem, zakłada się, że działa poprawnie z prawdziwym sprzętem. W rzadkich przypadkach symulator okazuje się błędny, ale jest to problem firmy szklarniowo-sprzętowej do rozwiązania, ponieważ nie symuluje poprawnie.

— Ross Patterson
źródło

OP nie wydaje się mieć gwarancji „symulatora”. Również w twoim przypadku pracodawca twojego kolegi prawdopodobnie może zażądać odszkodowania, jeśli symulator zawiedzie. Co PO może zrobić w podobnej sytuacji? Niepokoi Cię firma ubezpieczeniowa?

— K.Steff

4

Jeśli OP nie ma symulatora, musi go zdobyć - żebrać / ukraść / pożyczyć / zbudować - nie ma tak naprawdę znaczenia. Jak dobry musi być symulator - to jest coś, co musi zdecydować, a jeśli czuje potrzebę, może / powinien porozmawiać z firmą ubezpieczeniową na temat drobiazgu zwanego odszkodowaniem.

— mattnz

3

Są to sytuacje, w których najważniejsza jest dokumentacja API, dokumenty kontrolne interfejsu i emulatory. W firmie, w której wcześniej pracowałem, tak się często zdarzało, że zdarzało się to często w ramach projektu podczas niektórych faz integracji, w których jeden segment był gotowy, ale inne były opóźnione, pracują nad inną funkcją lub z innego powodu, którego nie udało się wdrożyć najnowsza wersja ich segmentu do naszego systemu testowego. Tak, tak naprawdę mieliśmy wierną replikę naszego środowiska produkcyjnego, na którym testowaliśmy; jednak w praktyce wszystkie segmenty nigdy nie były gotowe zgodnie z harmonogramem, ale interfejsy zostały uzgodnione i zablokowane przed rozpoczęciem rozwoju, a także stworzono emulatory, które w większości mogą naśladować zachowanie innych segmentów.

Jak wynika z innej odpowiedzi, emulator umożliwi testowanie przed wdrożeniem. Dobry emulator; zależy jednak od dobrze zdefiniowanych interfejsów i dokumentacji.

— Fred Thomsen
źródło

1

Cały czas jestem w takich sytuacjach.

Na pewno nie musisz wchodzić w interakcje z całą aplikacją, ale prawdopodobnie kilka interfejsów. Upewnij się, że masz potwierdzoną i szczegółową dokumentację interfejsów, a następnie skonfiguruj symulacje tych interfejsów tylko w celu sprawdzenia, czy dodany / zmieniony kod działa zgodnie z zamierzeniem.

Możesz także zrobić hybrydę. Spróbuj powielić części, które możesz dość łatwo zrobić, a następnie „połącz” się z prawdziwymi systemami (jeśli jest to możliwe w twojej sytuacji). Zrobiłem to z pewnym sukcesem - w niektórych przypadkach, gdy moja logika i oprogramowanie serwera były uruchamiane lokalnie, ale nadal miałem połączenia z prawdziwym systemem ERP w celu weryfikacji wywołań itp. Nie jest to idealne, ale rzadko tak jest.

Biorąc pod uwagę, że masz tylko system produkcyjny do pracy - pamiętaj, że nie możesz liczyć tylko czasu programistycznego zaoszczędzonego na konfigurowaniu repliki, ale musisz wziąć pod uwagę ryzyko biznesowe związane z użyciem w dużej mierze nieprzetestowanego kodu z aktywnymi danymi biznesowymi. Twój kod będzie mniej niezawodny niż kod przetestowany na replice. Czy systemy mogą być wyłączone przez jakiś czas? Czy można je przywrócić w przypadku uszkodzenia danych? Ile to kosztuje?

Najlepszą praktyką w przedsiębiorstwach jest umieszczanie repliki (lub więcej niż jednej) produkcji w momencie skonfigurowania środowiska produkcyjnego. W tym momencie dodatkowy koszt nie będzie tak duży.

— Petter Nordlander
źródło

1

Nasz system współpracuje z wieloma dużymi systemami zewnętrznymi. Łączymy następujące podejścia podczas ich testowania, jeśli nie mamy kompletnej konfiguracji od końca do końca:

Rekordowe odtwarzanie rzeczywistych danych. Nagrywaj prawdziwe dane (żądania / odpowiedzi z prawdziwych systemów zewnętrznych), w razie potrzeby parametryzuj je i odtwórz
Zbuduj lub kup symulator, który działa jak system zewnętrzny
DSL do generowania danych testowych. W przypadku systemów opartych na danych napisz DSL wysokiego poziomu do generowania danych testowych.

— dzieciou
źródło