Dołącz do grupy

Stwórz profil

Musisz wpisać swoje imię
Musisz wpisać swoje nazwisko
Musisz wpisać poprawny e-mail
Musisz wpisać hasło (min. 8 znaków)
Musisz zaakceptować regulamin

Maciej Kurowski Euler Hermes a
company of Allianz
Group, Director of
soft...

Temat: Zarządzanie środowiskami testowymi

Myślę ostatnio nad tematem z obszaru "IT environment management".

Opisuję poniżej pewnien "case" żeby maksymalnie skonkretyzować dyskusję. Celowo używam abstrakcyjnego języka, aby nie przywiązywać się do konkretnej branży lub technologii. Jestem pewien ze podobny problem w różnych mutacjach i skali występuje w każdej dużej organizacji IT.

Case:
W środowisku korporacyjnym (IT: 300+ osób) rozwijamy równolegle wiele aplikacji: A, B, C, ... . Przez "rozwój" rozumiem zarówno wdrożenia aplikacji w kolejnych oddziałach / u kolejnych klientów jak również obsługę kolejnych obszarów działalności np. wsparcie dla nowych produktów. Wdrożenia są zazwyczaj połączone z migracją danych. Kolejne wersje systemu rozszerzają również funkcjonalności istniejących modułów poszczególnych aplikacji. Ponieważ typowy cykl wdrożeniowy trwa pół roku, prace nad wersją n+2 są rozpoczynane w momencie gdy wersja n+1 jest gotowa w 50-60% a na produkcji działa wersja n.
Aplikacje A, B, C ... są silnie zinterfejsowane. Mamy pełne spektrum: interfejsy plikowe, web serwisy, kolejki itd. Każda z aplikacji ma swoje osobne środowisko wykonawcze (runtime environment). Zazwyczaj: serwer aplikacji w klastrze z load balancerem, baza danych, serwer http, ldap itd.

Problem:
Jak skutecznie zarządzać środowiskami testowymi. Chodzi o minimalizację kosztów, z drugiej strony prowadzenie jak najmniejszej liczby zależności pomiędzy projektami tzn sytuacji w których opóźnienie w jednym projecie automatycznie opóźnia wszystkie pozostałe.

Czekam na Wasze opinie. Szczególnie osób które zetknęły się z problemem w praktyce.Maciej Kurowski edytował(a) ten post dnia 18.05.11 o godzinie 09:46
18.05.2011, 09:45
Link do wypowiedziLink | Cytuj

Mikołaj W. Wyzwania, problemy
do rozwiązania i
inne atrakcje to
jest...

Temat: Zarządzanie środowiskami testowymi

Witam,

Rozumiem że chodzi o sytuację gdy aplikacja A korzysta z danych aplikacji B i wysyła wyniki swoich prac (przemyśleń :] ) do aplikacji C ?

Proponowałbym 3 duże środowiska:

1. Dev dla programistów - oni tam rządzą sobie jak im wygodniej.
2. TEST - dla wersji n+1.
3. Produkcja dla wersji n.

Rozumiem że prace związane z wersją n+1 są oparte o wymagania szczegółowe - to znaczy że "góra" lub inny zleceniodawca składa zamówienie na "nowy moduł raportujący integrujący dane z systemów spółek zaleznych celem zintegrowanej sprawozdawczości grupy kapitałowej". No to jak programiści opracują szczegółowe plany i wymagania zostaną dostarczone w formie papierowo-mailowo-spotkaniowej, to mają ok 50% roboty zrobionej (dane pobierają się do bazy, a teraz bierzemy się za interfejs i te nowe przyciski co mają mrugać jak zaloguje się Pani Dyrektor Finansowa :D).

Równocześnie dodawane są nowe wymagania dla wersji n+2 które zbierają się do kupki aż uzyskają "moc decyzyjną" otwarcia nowej wersji.

Powyższe celem zrozumienia sytuacji. Proszę o doprecyzowanie.

No to jedziemy z projektem:
1. DEV. Środowisko programistów z nadanymi uprawnieniami administratorów i ODRĘBNĄ DOMENĄ bez relacji zaufania. Za to "luźnym licencjonowaniem" liczby otwartych serwerów i baz danych. Jak programiści potrzebują nowego serwera to stawiają nowy obraz na wirtualnej (silnej) maszynie i wgrywają swój soft do testowania i deweloperki. Czyli wiele wirtualek, ale mało silnych serwerów. I mocne maszyny programistów które pełnią rolę preDev (z wymaganiem dostarczania wersji nie rzadziej niż co tydzień na wersję DEV.

2. TEST. Środowisko stabilnej aplikacji. Praktycznie identyczne z wersją produkcyjną wg relacji (liczba serwerów baz danych, liczba procesorów, liczba pamięci ram lub mniejsza). środowisko dopracowywania aplikacji pod względem utrzymania i działania. Miejsce testów akceptacyjnych zleceniodawców.

3. Produkcja. Tutaj każdy wie co ma w swojej serwerowej lodówce.

Co do rozdzielności aplikacji.

Metodyka segmentacji aplikacji pozwala na brak wpływu zmian na poszczególne aplikacje. Czyli robimy jedną aplikację interfejsową, która może działać równocześnie na jednym komputerze w wielu instancjach i ma jakąś tam stabilną wersję. Każda instancja może być przypisana do wersji aplikacji A, B, lub C. Można zastosować wersje mniejsze (minor) i większe (major) - minor robi zmiany tylko w swoim poletku, ale z zewnątrz jest przeźroczysta, natomiast major robi zmiany w więcej niż jednej aplikacji. Celem jest zgodność wstecz utrzymywana nie krócej niż 1 rok (czyli dwa cykle aplikacji A, B, C).

Ja bym tak do tego podszedł. Na gorąco i na szybko napisane.

Pozdrawiam,
MWW
20.05.2011, 20:22
Link do wypowiedziLink | Cytuj

Michał Stachura Spełniam marzenia
:) www.santri.pl

Temat: Zarządzanie środowiskami testowymi

Witam,

Próbuję to sobie ułożyć na kartce papieru i jeśli dobrze rozumiem w tej chwili masz trzy wersje oprogramowań.
N - produkcyjne wersje aplikacji
N+1 - najbliższy upgrade produkcyjny
N+2 - kolejny upgrade produkcyjny

Aplikacji jest bez liku A,B,C ... Z

Co prawda nie piszesz szczegółów ale zakładam, że rozpoczynając prace nad N+2 w momencie gdy N+1 jest gotowe w 60% masz tu na myśli prace analityczne, zbieranie wymagań, przygotowywanie prototypów, podpisywanie umów, ustalanie ryzyk etc. czyli wszystko co związane z projektem a jeszcze samym grzebaniem w kodzie nie jest.
Jeśli tak to to co pisze Mikołaj jest (powinno być) całkowicie wystarczające. Problemy mogą się pojawić jeśli nad aplikacjami pracują różne grupy informatyków i jedna z nich skończy już prace nad swoją aplikacją a druga jeszcze wygrzebuje się z błędów swojej aplikacji. Pół biedy jak informatycy siedzą w jednym pomieszczeniu, gorzej jak są rozrzuceni po Polsce (świecie). Najprościej można by powiedzieć: "czekajcie aż zespół XXX zrobi projekt aplikacji B a wy teraz odpoczywacie".
Tylko zarząd może nieco krzywo patrzeć na takie rozwiązanie :).

W firmach gdzie jest kilka różnych aplikacji korzystających z tych samych serwerów bazodanowych, aplikacje te jednocześnie są ze sobą mocno powiązane i wchodzą w interakcje, a zespół informatyków nie jest oparty na freelancerach, których można ale nie trzeba zatrudniać, można teoretycznie próbować tworzyć środowiska jak pisze Mikołaj, ewentualnie wesprzeć je jeszcze jednym środowiskiem akceptacyjnym, który oprócz bycia kopią produkcji ma także zgrywane z produkcji raz na jakiś czas bazy danych.
I to zapewne będzie działać lepiej lub gorzej w zależności od instytucji. Najpewniej w miarę rozrostu aplikacji trzeba będzie coraz więcej czasu poświęcać na sama obsługę kolejnych aktualizacji, dział release managerów będzie rósł, testerzy będą mieli pełne ręce roboty a PM będą mieć coraz więcej wyrwanych włosów na głowie :).

Ostatnio próbuję sobie ułożyć w głowie model oparty na mniejszych zasięgowo aktualiazcjach ale realizowanych częściej i z całkowicie pominiętym harmonogramem upgradeów określanym przeważnie gdzieś na początku roku a już w pierwszym kwartale wymagającym korekt i modyfikacji :).
Jako niewielki sukces uznaję na razie nieco bardziej przychylne spojrzenie na zaproponowaną ideę i... być może coś z tego będzie. W każdym bądź razie trzeba nadal drążyć tą korporacyjną skałę. Przykładowo google realizuje 400 upgradeów rocznie. Ponad jeden dziennie :).
23.05.2011, 00:10
Link do wypowiedziLink | Cytuj

Maciej Kurowski Euler Hermes a
company of Allianz
Group, Director of
soft...

Temat: Zarządzanie środowiskami testowymi

Dziękuję za opinię.

Gwoli ścisłości:
Poszczególne projekty są tworzone przez niezależne zespoły rozsiane po świecie.
Pracę nad kolejnymi wersjami oprogramowania: n+1 / n+2 trwają równocześnie w takim sensie, że podczas testów i bugfixingu n+1 trwa już rozwój n+2.

Co do liczby samych środowisk, jesteśmy zgodni:
Prod - środowisko produkcyjne
N1, N2 - środowiska testów funkcjonalnych dla wersji aplikacji odpowiednio n+1 / n+2.
Spotkałem się praktyką poprzedzania poprzedzania każdego ze środowisk, osobnym środowiskiem integracyjnym (IN1, IN2), tak aby mieć pewność, że aplikacja wdrożona na N1, N2 startuje i podstawowe interfejsy działają.

Dodatkowo środowisko do testów ewentualnych hotfixów dla wersji produkcyjnej.
PreProd - kopia prod.

Jeśli zakładamy migrację danych, potrzebujemy kolejnego środowiska read-only aby ją przetestować: Migr.

Osobiście mam kilka problemów z tym typowym układem:
- Wszystkie aplikacje w wersji n+1 / n+2 są testowane w jednym środowisku. Możemy je więc wdrożyć wyłącznie wszystkie na raz. Dodatkowo opóźnienie w jakimkolwiek projekcie potencjalnie opóźnia wszystkie pozostałe projekty.
Nie znam korporacji stosującej tę strategię i mogącej sobie pozwolić na więcej niż kilka wdrożeń w ciągu roku.

- W każdym ze środowisk: n+1 / n+2 interfejsujemy z sobą wiele niestabilnych aplikacji. Podczas testów błędy się kumulują. Np interfejs angażujący 5 aplikacji, z których każda nie działa z prawdopodobieństwem 10% nie działa z prawdopodobieństwem 40%.

Jak radzicie sobie z tymi tematami?
23.05.2011, 09:43
Link do wypowiedziLink | Cytuj

Michał Stachura Spełniam marzenia
:) www.santri.pl

Temat: Zarządzanie środowiskami testowymi

:) Opis tak jakby z mojego środowiska w jakim pracuję.
Radzimy sobie jak umiemy czyli korekty, dogrywki, poprawki... nerwy.

Hipotetycznie próbuję sobie wyobrazić taką infrastrukturę środowisk i przekonać do niej przełożonych gdzie mamy cztery środowiska.
1. Developerskie
2. Testowe
3. Akceptacyjne (migracyjne)
4. Produkcyjne

Developerzy pracują na swoimi aplikacjami na środowisku developerskich i nikt tam im się nie wtrąca. Developer robi także przed wgraniem na środowisko testowe weryfikację swoich zmian pod kątem opisanych w dokumentacji projektowej scenariuszy testowych.

Testowe środowisko jest zasilane przez informatyków paczkami zmian dotyczącymi konkretnych aplikacji i przygotowywanych przez poszczególne zespoły informatyków. Paczka zmian dotyczy tylko i wyłącznie zmian programowanych przez dany zespół.
Na środowisku tym po aplikacje sprawdzane są (punktowo) przez niezależny zespół testerów. Jeśli są błędy wtedy poprawki dokładane są do paczki aktualizacyjnej aż do wyczyszczenia wszystkich błędów.

Na akceptacyjnym (migracyjnym) po przekroczeniu masy krytycznej (niezależnie od harmonogramów upgradeów na podstawie decyzji biznesowej) zostają dograne wszystkie zamknięte na testowym środowisku bezbłędne aplikacje i zlecone testy integracyjne plus testy procesów działania całości systemu. Przed testami dobrze by było jeszcze zrobić zrzut produkcyjnej bazy danych bo to na mniejszej może działać dobrze, a na większej czasem już jakieś kwiatki wydajnościowe wychodzą :).
W przypadku gdy nie ma problemów (raczej niemożliwe :) paczki wgrywane na środowisko akceptacyjne przenoszone są na produkcyjne. Dla sytuacji gdzie mamy problem przygotowujemy kolejne poprawki i dogrywamy tą samą ścieżką. Ważne jest, żeby dokładnie zapisywać kolejność wykonywania poszczególnych paczek.

Na koniec wyłączamy na chwilę produkcję i wgrywamy wszystkie paczki na produkcję. Ryzyka całkowicie nie unikniemy ale przy takim podejściu jeśli środowisko akceptacyjne jest w miarę wierną kopią produkcyjnego powinno wszystko grać.
Dodatkową korzyścią takiego podejścia jest to, ze projekty ważne nie muszą czekać aż wszystkie inne zaplanowane na upgrade zostaną wykonane. Po prostu decyzją biznesową zostają wgrane zmiany z TST na Akcepta i upgrade zostaje wykonany. Unikamy tu sytuacji gdy ważny biznesowo projekt czeka na jakiś maruderów, którzy generują błędy :). Informatycy mają tu też ciągłość pracy bo jak skończą prace nad aplikacją A, która jest przenoszona na produkcję mogą na środowisku developerskim rozpocząć prace nad aplikacją B przygotowując ja do wgrania.
23.05.2011, 10:45
Link do wypowiedziLink | Cytuj

Maciej Kurowski Euler Hermes a
company of Allianz
Group, Director of
soft...

Temat: Zarządzanie środowiskami testowymi

Konfiguracja którą proponujesz wygląda ok, ale kilka problemów pozostaje:

- Nadal występuje problem kumulacji defektów (tzn wiele niestabilnych aplikacji zinterfejsowanych w jednym środowisku).
Wygląda bezboleśnie, ale realizując architekturę SOA, w której każdy proces biznesowy jest realizowany przez serwisy kilku(nastu)aplikacji szukanie defektów jest jak poszukiwanie igły w stogu siana.
W dodatku rozmowa się odpowiedzialność. Team odpowiedzialny za każdą z aplikacji powie: "a u nas działa ...".

Luźne pomysły: wstępne testy aplikacji "solo" z użyciem mockupów? Być może kreatywne użycie Serwera Integracyjnego z możliwością zastąpienia serwisów oferowanych przez aplikacje mockupami? Interfejsowanie aplikacji w wersji rozwojowej z pozostałymi aplikacjami w wersji stabilnej?

- Nie wyobrażam sobie testów migracji w środowisku akceptacyjnym. Każda migracja danych czyści przypadki testowe.

- Nie zawsze można zasilać środowisko testowe danymi z produkcji (szczególnie w banku :). A propos tego tematu, pamiętam minę dostawcy oprogramowania któremu do testów dostarczono dane "zanonimizowane". Struktura danych i relacje były zachowane, ale treść: nazwy, nipy, adresy itd była po prostu wylosowana.
26.05.2011, 08:24
Link do wypowiedziLink | Cytuj

Michał Stachura Spełniam marzenia
:) www.santri.pl

Temat: Zarządzanie środowiskami testowymi

Zgadzam się, że opisana konfiguracja na pewno nie jest rozwiązaniem dla wszystkich i dla każdego środowiska. To tylko idea wymagająca doszczegolowienia i dostosowania do konkretnych firm i konkretnych środowisk.
Problem przerzucania odpowiedzialności to standard zwłaszcza wśród informatyków gdzie przecież każdy programista wie, że jego kod jest najlepszy na świecie i na pewno jest całkowicie pozbawiony wad :-)

Na pewno ten temat jest ciekawy, w zasadzie jak wszystko w ogólnie pojętej tematyce projektów IT, na pewno też nie ma idealnego rozwiązania pasujacego wszędzie. Na pewno też można by przy niejednym piwku o tym sporo dyskutować :-).
27.05.2011, 00:49
Link do wypowiedziLink | Cytuj
« Wróć do tematów
Odpowiedz
Dołącz do grupy



Wyślij zaproszenie do

Anuluj