Używam marionetki do wdrażania infrastruktury, a większość pracy, którą wykonuję, dotyczy firm Web 2.0, które intensywnie pracują nad testowaniem swoich aplikacji internetowych. Czy ktoś tutaj stosuje podejście testowe do rozwijania swoich konfiguracji serwerów? Jakich narzędzi używasz do tego? Jak głęboko sięgają twoje testy?
Odpowiedzi:
Nie sądzę, żebyś mógł użyć programowania opartego na testach . Ale na pewno możesz spróbować testów jednostkowych na nowych serwerach.
Zasadniczo musisz wdrożyć serwery, uruchomić usługi w trybie testowym, a następnie uruchomić testy z innego serwera (lub serii serwerów) względem usług. Następnie w końcu umieść je w produkcji.
Może za pomocą skryptów Python do łączenia się z bazami danych, stronami internetowymi i usługami ssh. A następnie zwróć PASS / FAIL. Byłby dla ciebie dobry początek.
Lub możesz po prostu zwinąć to w rozwiązanie monitorujące, takie jak Zenoss, Nagios lub Munin. Następnie możesz przetestować podczas wdrażania; I monitoruj podczas produkcji.
Myślę, że Joseph Kern jest na dobrej drodze z narzędziami do monitorowania. Typowy cykl TDD to: napisz nowy test, który się nie powiedzie, a następnie zaktualizuj system tak, aby wszystkie istniejące testy przeszły pomyślnie. Łatwo byłoby to dostosować do Nagios: dodaj test negatywny, skonfiguruj serwer, ponownie uruchom wszystkie kontrole. Pomyśl o tym, czasami robiłem dokładnie to.
Jeśli chcesz być naprawdę hardkorowy, napisz skrypty sprawdzające każdy istotny aspekt konfiguracji serwera. System monitorowania, taki jak Nagios, może nie być odpowiedni dla niektórych z nich (np. Możesz nie „monitorować” swojej wersji systemu operacyjnego), ale nie ma powodu, dla którego nie mógłbyś odpowiednio łączyć i dopasowywać.
Chociaż nie byłem jeszcze w stanie robić TDD z manifestami Puppet, mamy dość dobry cykl, aby zapobiec wprowadzeniu zmian do produkcji bez testowania. Mamy dwóch założycieli marionetek, jeden jest naszym marionetkiem produkcji, a drugi naszym marionetkiem rozwoju. Używamy „środowisk” Puppet, aby skonfigurować następujące elementy:
Nasi programiści aplikacji pracują na maszynach wirtualnych, które uzyskują konfiguracje Puppet ze środowiska programistycznego Puppetmaster. Gdy opracowujemy manifesty Puppet, zwykle konfigurujemy maszynę wirtualną, aby służyła jako klient testowy podczas procesu programowania i wskazywała na nasze osobiste środowisko programistyczne. Gdy jesteśmy zadowoleni z naszych manifestów, wypychamy je do środowiska testowego, w którym twórcy aplikacji otrzymują zmiany na swoich maszynach wirtualnych - zwykle narzekają głośno, gdy coś się psuje :-)
Na reprezentatywnym podzbiorze naszych maszyn produkcyjnych znajduje się druga kukiełka działająca w trybie noop i wskazana na środowisko testowe. Używamy tego, aby wychwycić potencjalne problemy z manifestami, zanim zostaną one zepchnięte do produkcji.
Gdy zmiany minęły, tzn. Nie psują maszyn dewelopera aplikacji i nie generują niepożądanych wyników w logach procesu marionetkowego „noop” maszyn produkcyjnych, wprowadzamy nowe manifesty do produkcji. Mamy mechanizm wycofywania, dzięki czemu możemy wrócić do wcześniejszej wersji.
Pracowałem w środowisku, które właśnie przechodziło migrację do modelu operacyjnego TDD. W przypadku niektórych skryptów monitorujących działało to bardzo dobrze. Użyliśmy buildbot do skonfigurowania środowiska testowego i uruchomienia testów. W takim przypadku podchodzisz do TDD z perspektywy „Legacy Code”. W TDD „Legacy Code” to istniejący kod, który nie ma testów. Tak więc pierwsze testy nie kończą się niepowodzeniem, definiują prawidłowe (lub oczekiwane) działanie.
W przypadku wielu zadań konfiguracyjnych pierwszym krokiem jest sprawdzenie, czy usługa może zostać przeanalizowana. Wiele usług zapewnia pewne udogodnienia, aby to zrobić. Nagios ma tryb inspekcji wstępnej, cfagent nie działa, apache, sudo, bind, a wiele innych ma podobne funkcje. Jest to w zasadzie przebieg kłaczków dla konfiguracji.
Przykładem może być użycie apache i oddzielnych plików konfiguracyjnych dla różnych części, możesz przetestować części, a także po prostu użyć innego pliku httpd.conf, aby owinąć je w celu uruchomienia na komputerze testowym. Następnie możesz sprawdzić, czy serwer WWW na maszynie testowej daje tam prawidłowe wyniki.
Na każdym kroku postępujesz według tego samego podstawowego wzoru. Napisz test, zdaj test, refaktoryzuj swoją pracę. Jak wspomniano powyżej, podczas podążania tą ścieżką testy nie zawsze kończą się niepowodzeniem w zaakceptowanym trybie TDD.
Rik
Uważam, że poniższe linki mogą być interesujące
cucumber-nagios - projekt, który pozwala zamienić pakiet Cucumber w wtyczkę Nagios i który zawiera definicje kroków dla SSH, DNS, Ping, AMQP i ogólne rodzaje zadań „wykonaj polecenie”
http://auxesis.github.com/cucumber- nagios /
http://www.slideshare.net/auxesis/behaviour-driven-monitoring-with-cucumbernagios-2444224
http://agilesysadmin.net/cucumber-nagios
Istnieje również pewien wysiłek po stronie Puppet / Python http://www.devco.net/archives/2010/03/27/infrastructure_testing_with_mcollective_and_cucumber.php