Blog

W artykule automatyzacja z lotu ptaka pisaliśmy o istocie automatyzacji. Z kolei tekst dzisiejszy prezentuje szereg dobrych praktyk i w ten sposób opowiada na pytanie „jak automatyzować?”. Podzieliliśmy je na dwie grupy: ogólne oraz związane ze środowiskami deweloperskimi.

Ogólne

Miej świadomość: co i dlaczego

Niby oczywiste, ale w codziennym pośpiechu nieraz umyka nam cel. Przed przystąpieniem do automatyzacji musimy posiąść gruntowną wiedzę na temat tego, co automatyzujemy. Pozwoli nam to dokonać trafnych wyborów, oszczędzi wiele czasu zarówno na przy tworzeniu, jak i utrzymaniu produktu. Dlatego warto poświęcić czas i zadać parę niewygodnych pytań.

Gdy tworzymy testy automatyczne, wiedza ta umożliwia nam ocenę tego, które testy warto automatyzować, które lepiej pozostawić do testowania ręcznego, jak rozłożyć testy danej funkcjonalności w piramidzie testów, a także pozwala tworzyć rozsądne testy interfejsu graficznego.

Jeśli automatyzujemy procesy, wiedza ta jest równie ważna. Częstym błędem podczas automatyzacji lub przenoszenia procesu do chmury jest jego odwzorowanie 1:1. Bez analizy, co jest jego istotą, a co naleciałością z poprzednich narzędzi, przyzwyczajeń, procesów – przodków itd.

Automaty to też kod…

Wszystkie dobre praktyki deweloperskie tak samo ich dotyczą. Zatem kod, który powstaje w wyniku automatyzacji, powinien być umieszczony w kontroli wersji, poddany przeglądowi kodu (code review), powinno się w nim stosować wzorce projektowe itd.

W systemie kontroli wersji przechowuj absolutnie wszystko

W wersji minimum powinniśmy trzymać wszystko, co jest konieczne do odtworzenia binariów aplikacji oraz środowisk, w których aplikacja pracuje.

Poza tym przydatne jest ewidencjonowanie wszystkiego, co jest potrzebne do wytworzenia, wdrożenia, przetestowania i udostępnienia aplikacji. Zatem analitycy powinni trzymać dokumentację wymagań, testerzy testy automatyczne, ale też scenariusze testów manualnych. Managerowie projektów powinni przechowywać tutaj plany wydawania kolejnych wersji i postępy prac. Krótko mówiąc, każdy członek zespołu powinien trzymać w systemie kontroli wersji wszystkie pliki i dokumenty związane z projektem, tak aby możliwe było odtworzenie migawki (snapshot) całego systemu od środowiska programistycznego po produkcyjne z dowolnego momentu trwania projektu.

Przechowujemy wszystko, aby móc z łatwością odtwarzać. W rezultacie samych binariów aplikacji nie przechowujemy. Są duże i szybko się mnożą, a łatwo się je odtwarza z tego, co już w repozytorium mamy.

Dbaj o krótką pętlę zwrotną

Staraj się o jak najkrótszą pętlę zwrotną. Im szybciej dostaniesz informację, tym lepiej.

Można iść dwutorowo – z jednej strony starać się, aby procesy były wykonywane jak najszybciej np. poprzez zwiększenie zasobów, lepsze narzędzia itd. Z drugiej można je projektować tak, aby jak najszybciej zawiodły (fail fast). Na przykłady zweryfikować wszystkie dane wejściowe przed przystąpieniem do ich obróbki, dzięki czemu mamy pewność, że żadne obliczenia nie zostaną wykonane, jeśli nie mają sensu.

Jedną z dobrych praktyk ciągłej integracji jest odrzucanie zmian, ze względu na zbyt długo trwające testy (innymi słowy, ze względu na zbyt długie oczekiwanie na informację zwrotną).

Środowiska develeoperskie

Każdy projekt powinien mieć co najmniej 3 środowiska. Pierwsze to środowisko programistyczne – tu projekt powstaje. Najczęściej jest to po prostu stacja robocza programisty. Ostatnim jest środowisko produkcyjne – tutaj aplikacja działa i w zależności od jej natury może to być np. serwer webowy, klaster, albo stacja robocza klienta. Pomiędzy nimi jest jeszcze co najmniej jedno środowisko, które nazywane jest bardzo różnie np.: tymczasowe, certyfikacyjne, akceptacyjne. Powinno być ono jak najwierniejszą kopią produkcji. Czasami są to wydzielone serwery na produkcji. W innych projektach odtworzenie środowiska produkcyjnego jest tak drogie, że odtwarza się jedynie jego najważniejsze ograniczenia, czyli np. dla aplikacji pracującej w klastrze tworzy się mini klaster z dwóch serwerów, a dla systemu rozproszonego odtwarza się po jednym węźle danego typu.

W bardziej zaawansowanych projektach tworzone są jeszcze środowiska do testów wydajnościowych albo środowisko integracyjne.

Kompiluj tylko raz

Niektóre systemy kompilacji używają kodu źródłowego zewidencjonowanego w systemie kontroli wersji jako kanonicznego źródła wiedzy. Przez co na każdym etapie potoku wdrożeń odwołują się do niego i kompilują kod na nowo. Różnice między środowiskami np. w wersji kompilatora, mogą doprowadzić do różnic w skompilowanych binariach.

Kod powinien być skompilowany tylko raz i te same binaria powinny być używane w każdej fazie potoku. Chcemy mieć pewność, że to, co wdrożyliśmy na produkcję, jest dokładnie tym samym, co testowaliśmy. Dodatkowo kompilując częściej, wydłużamy pętlę informacji zwrotnej.

Promuj zmianę

Każda zmiana powinna przejść przez każde środowisko, przechodząc poprawnie wszystkie przeprowadzane w nim testy. Czyli np., gdy w środowisku integracyjnym przeszła pozytywnie testy integracyjne zostaje wypromowana do środowiska testów wydajnościowych.

Wszędzie wdrażaj tak samo

Ryzyko związane z wdrożeniem jest odwrotnie proporcjonalne do częstotliwości wdrożenia. Na stacji roboczej programisty wdrażasz non stop, na produkcji raczej rzadko, a to ona jest najważniejsza. Dzięki takim samym skryptom na wszystkie środowiska masz pewność, że są dobrze przetestowane.

Oczywiście środowiska się różnią, więc potrzebny będzie plik konfiguracyjny dla każdego, ale w razie niepowodzenia od razu zawęża nam się krąg podejrzanych. Winnym może być plik konfiguracyjny skryptu, infrastruktura lub usługa, od której aplikacja zależy albo też sama konfiguracja środowiska. W każdym razie nie musimy marnotrawić cennego czasu na analizowanie poprawności skryptu.

Stosuj testy dymne

Upewnij się, że aplikacja naprawdę działa. Testy dymne albo też testy wdrożenia powinny sprawdzić, czy aplikacja się uruchomiła, czy działa i czy usługi, od których jest zależna, działają poprawnie. W razie niepowodzenia należy określić, który z tych elementów zawiódł. Nie musi to być nic więcej niż uruchomienie aplikacji, sprawdzenie, czy na ekranie głównym wyświetla się pożądany napis oraz, czy działa połączenie z bazą danych.

W kolejnej części cyklu napiszemy jeszcze więcej o samych testach i ich automatyzacji.