Temat: Środowiska - czyli ogarnianie chaosu

Interesuje mnie wymiana doświadczne, know-how i tym podobnych na temat zarządzania środowiskami u Was w firmach. U siebie obecnie mam masakrę, próbuję to powoli transformować, chętnie usłyszę historie innych.

U nas generalnie nie ma osoby stricte odpowiedzialnej za środowiska i póki co te środowiska są w stanie opłakanym. Jest nas para testerów i para sys engineerów, którzy pomagają w ustawieniu serwera, no i deweloperzy, którzy pomagają w konfiguracji tego, co postawili sys'owie.

Jedno środowisko składa się z kilku części, które mogą i często są na różnych serwerach na różnych platformach. Jest serwer aplikacji, baza danych i ileś tam różnych komponencików (które zawsze są zespołowo, więc można je dla uproszczenia traktować jako jednolitą całość). Jest Windows, Linux, Solaris, AIX i Mainframe, DB2 i Oracle, jBoss i WebSphere.

Testerzy chcą QA i integracje, managerowie chcą mieć środowisko mirror produkcji (którym mają się zajmować testerzy), developerzy najbardziej to by chcieli korzystać ze środowiska QA, bo jest pełne i na bieżąco uaktualniane.

Zastanawiam się jak to wszystko ogarnąć. Jak zorganizować, jak tym potem zarządzać, kto powinien być za co odpowiedzialny, no i w ogóle - jak nie zginąć...

Opisałam po krótce swoją sytuację dla przybliżenia o jakie sytuacje mi chodzi, ogólnie liczę raczej nie na konkretne rady "zrób to" (bo i też niemożliwe jest na podstawie tak szczątkowych informacji doradzić). Interesuje mnie natomiast doświadczenie osób w podobnej sytuacji :) Jak wy to ogarniacie? :)

Temat: Środowiska - czyli ogarnianie chaosu

Ta tematyka to jedna z najważniejszych ale przez to i najobszerniejszych tematyk zarządzania, zarządzanie konfiguracją (configuration management). Tak że ciężko będzie odpowiedzieć w jednym poscie albo nawet wątku :)

Na początek trzeba by wszystko spisać, tj. dopracujcie instrukcje. Do każdej instrukcji jedna odpowiedzialna osoba która zbiera obserwacje i uwagi od reszty teamu i to wszystko skleja. W końcu pytań jest coraz mniej i instrukcje się stabilizują.

No i jak się da automatyzmy, skrypty itd.

Dobrym testerem instrukcji i skryptów są nowi pracownicy, tacy którzy robią daną rzecz, np. ustawiają środowisko, pierwszy raz.

Resztę trzeba już przemyśleć i ustalić, i spisać, w configuration management planie. Sposobów może być milion a to Wy wiecie który jest najlepszy ;) Tam wprowadzić zasady, np że developerzy nie mogą korzystać ze stanowisk testerów, określić różne konfiguracje (ta dla mgmt, ta dla Was, inne), itd. Dojście do tego nie jest łatwe więc nie wahaj się organizować spotkań by to uporządkować, dogadać, dobrze zrozumieć ograniczenia i potrzeby. I uświadom managementowi że potrzeba na to czasu, czyli ZAPLANUJ te czynności, realnie, co kiedy zostanie osiągnięte. Kontroluj potem ten plan.

Poszukaj po sieci przykładów Configuration Management Plan'ów, to może coś podsunąć.

Możesz też przeczytać mojego ulubieńca (bo jest treściwy) czyli AutomotiveSPICE Process Assessment Model rozdział SUP.8 Configuration Management, tam zastanów się nad każdą z Base Practicies (BP).

A na samym końcu zabaseline'uj to, tj ustal wersję CMPlanu, wszelkich tooli, instrukcji i wszelkich CM items które są używane w danym okresie i wprowadź zarządzanie zmianą konfiguracji.

I przydziel osobę odpowiedzialną za CM, wprowadź taką rolę w projekcie.

Wiem że chaotycznie i może niejasno ale jak mówię, to potężny temat, więc pisz które części rozwijać :)

Temat: Środowiska - czyli ogarnianie chaosu

Z tego co piszesz zespół jest niewieleki i liczba systemów (softu, który ma być testowany) także, więc nie przesadzałbym z jakimiś wodotryskami w postaci opasłych procesów zarządzania zmianą, tylko skupił się na stworzeniu procesu pod konkretny system/problem. Bo zdaje się to jest celem, a nie globalne zmiany w sposobie zarządzania infrastrukturą i procesami organizacji?

Podstawową rzeczą wydaje mi się repzytorium dokumentów/softu (każdy projekt powinien takowe posiadać), w których będą trzymane informacje o środowiskach, wersje softu, narzędzia. Tu w zupełności wystarczy jakiś dysk sieciowy.

W wersji minimum sprawdzą się arkusze excelowe z wersjonowaniem przez podanie timestampa w nazwie pliku ;-)

Co sledzić:
- środowiska (maszyny, użytkownicy, hasła, końcowki interfejsów, firewalle)
- zmiany (co zmieniane, gdzie, ktora wersja, kiedy, przez kogo)
- zależności (komponent X w wersji a jest zgodny z komp. Y w wersji v. 1,2,3 itd.)

Co dalej:
- ustandaryzować procedurę instalacji - najlepiej podzielić instlację na rózne komponenty, tak by każdy miał swoją
działke, np. DBA, Unix ADM, JBoss ADM, WebSphere ADM itd. (być może jedna osoba będzie pełnić kilka ról). Ważne jest by te "działki" byly rozdzielne
- zautomatyzować procedurę instalacji, tam gdzie ma to sens
- ustandaryzować proces odświeżania środowiska - czasem powstaje chlewik i warto by postawic grubą krechę nad obecnym stanem środowiska i po prostu "odświezyć" z produkcji
- wprowadzić instytucję "release managera", która będzie koordynowała proces instalacji / rozdzielala zadania / dbała o porządek w repozytorium

Typowy obrazk środowisk w dojarzałej organizacji często odbiega od ideału, który można by zobrazować tak:
PRD - produkcja
QA - wierna kopia PRD (hardware/soft) - przeprowadzane są tu testy funkcjonalne / wydajnościowe / ...
INT/CST - do testowania interfejsów z innymi systemami (nie tak wierna kopia produkcji)
DEV - chlewik deweloperów

Z tego co zauważyłem odbieganie od ideału wynika z:
a) braku hardware, na którym można by zainstalować kopie produkcji
b) braku zewnętrznych systemow, do których środowisko developerskie mogłoby się podłączyć
c) przestarzale dane na środowisku
d) dane popsute przez użytkowników

Jak temu zaradzić:
a) DEV przygotowują procedurę ekstraktu danych z produkcji, ale np. 1% albo 10% (zależy od wolumenu) lub mają taki
system zainstalowany wirtualnie, tj. jakis VMWare czy coś podobnego
b) DEV przygotowuja zaślepki do interfejsów (interfejsy powinny byc testowane na INT)
c) aplikujemy procedure odświeżenia środowiska z produkcji
d) tu można mieć różne strategie, jednak wymagające specyficznej wiedzy technicznej np.:
- korzystać z dobrodziejstw wirtualizacji i przygotować raz obraz systemu dla vmware, a jak sie popsuje, to uruchomic z poprzedniej wersji
- Solaris oferuje snapshoty file systemu, wiec mozna powrócić do jakiejs konkretnej wersji (o ile sie snapshot zrobiło :)
- Oracle (odtworzenie bazy z backupu, flashback database)

Generalnie temat szeroki :)

Temat: Środowiska - czyli ogarnianie chaosu

Ja tylko dopowiem do swojego że bynajmniej nie miałem na myśli nic opasłego albo rozmiarowo niewygodnego i nie wiem dlaczego tak się to kojarzy ;) Ma być praktyczne (a może być przy okazji właściwie nazwane co też uczyniłem :) ).

Temat: Środowiska - czyli ogarnianie chaosu

.Jacek Kruszewski edytował(a) ten post dnia 11.12.09 o godzinie 10:54