Blog

Na naszym blogu można znaleźć wiele artykułów poświęconych automatyzacji, między innymi serię o Ansible. W tym tekście zrobimy krok w tył, żeby zobaczyć automatyzację w szerszej perspektywie. Przyjrzymy się jej roli w DevOps oraz powiemy wysokopoziomowo o samej automatyzacji.

Automatyzacja a DevOps

Automatyzacja w dużym skrócie to oddanie pracy ludzkiej w ręce maszyn. Dużo trudniej zdefiniować owiany sławą DevOps, ale większość osób zgadza się, że jego podstawowymi wartościami są: kultura, automatyzacja, mierzenie oraz współdzielenie. To bardzo ważny kontekst dla automatyzacji. Chroni ją przed byciem sztuką samą w sobie.

Kultura DevOps promuje współpracę między ludźmi na różnorodnych stanowiskach, w różnych działach firmy. Dobra wymiana wiedzy i informacji sprzyja adresowaniu problemów, które są najbardziej kluczowe, w których stopa zwrotu z inwestycji w automatyzację jest największa. Pomaga też zapobiegać tworzeniu się wąskich gardeł na styku różnych działów przedsiębiorstwa.

Mierzenie pozwala ocenić, czy naprawdę idziemy we właściwą stronę. Monitoring szybko ostrzega o błędach powstałych w wyniku źle działającego automatu albo o jego wyłączeniu. Twarde, namacalne liczby mogą także pomóc przekonać zarząd o zasadności poświęcania czasu pracowników na automatyzację.

Współdzielenie jest oparte na informacji zwrotnej (feedback). Skuteczność informacji zwrotnej zależy od szybkości, z jaką się ją otrzyma. Im wcześniej ją dostajemy, tym lepiej wykorzystujemy. Unikamy powtarzania tych samych błędów, ale też z większą łatwością poprawimy już istniejące. Zupełnie inaczej nanosi się bowiem poprawki do pracy pisanej wczoraj lub miesiąc temu niż do tej sprzed pół godziny. Odpowiednia automatyzacja zapewnia błyskawiczną informację zwrotną w naprawdę wielu obszarach jak na przykład: poprawnego działania aplikacji na poziomie behawioralnym, utrzymaniu czystego kodu, wydajności czy też spełnianiu standardów prawnych (np. PCI).

Dodatkowo automatyzacja sama z siebie sprzyja dzieleniu się wiedzą – żeby coś zautomatyzować, trzeba to spisać. W ten sposób tworzy się nam żywa dokumentacja zachodzących procesów (oczywiście o ile dba się o to, by kod był samodokumentujący się).

Automatyzacja

Wiemy już, jak automatyzacja wpisuje się w DevOps, zatem przyjrzyjmy się jej teraz nieco bliżej. Nad definicją nie ma co się rozwodzić – jaki koń jest, każdy widzi. Przejdźmy do bardziej praktycznych pytań: co automatyzować? Jak? Czym? Kiedy zacząć? Kiedy przestać?

Co automatyzować?

Wszystko. Co nie znaczy, że wszystko trzeba. A już z pewnością nie wszytko naraz. Cudownie jest wyobrażać sobie, że nasz produkt podlega ciągłemu dostarczaniu użytkownikowi (Continuous Delivery), że nasz commit zostanie udostępniony użytkownikom już nawet po paru godzinach. Jak na przykład w LMAX, gdzie każdy commit jest weryfikowany przez 20 000 testów jednostkowych, ponad 3 000 testów integracyjnych oraz 10 000 testów akceptacyjnych i to wszystko w 20 minut. Tylko że zaraz trzeba wrócić na ziemię. LMAX automatyzował swój proces wytwarzania oprogramowania przez wiele lat, wydając na nie niesamowite sumy. Jednak było warto – teraz niemal od razu są w stanie zidentyfikować zmianę, która zagraża projektowi. Jak to osiągnąć? To następne pytanie.

Jak?

Krok po kroku. Z jasnym celem, niekoniecznie ambitnym. Nadrzędnym priorytetem jest to, aby produkt podobał się klientom i aby chętnie za niego płacili. Biznesu nie interesuje, jak jest wytwarzany, dopóki jest na czas i odpowiedniej jakości. Zatem na początku możemy mieć niewiele czasu, jednak w miarę postępu pracy będzie go przybywać – w końcu coraz więcej rzeczy będzie się wydarzać automatycznie – bez naszego udziału. Będziemy cieszyć się efektem kuli śnieżnej.

Od czego zacząć?

Czyli tak naprawdę wracamy do pytania „co?”. Każdy team, projekt, firma jest inna, więc uniwersalnej odpowiedzi nie ma. Są za to uniwersalne pytania, którymi można się sugerować: co przyniesie najwięcej zysku? Co wykonujemy najczęściej? Czego najbardziej nie lubię wykonywać? Gdzie najczęściej pojawiają się błędy ludzkie (znowu zapomnieliśmy o …)? Które błędy są najbardziej kosztowne?

Naszym kandydatem na pierwszy ogień są testy. Powodów jest kilka: przede wszystkim testy automatyczne gwarantują utrzymywalność projektu – bez testów strach cokolwiek zmienić. Jeśli marzy się nam pełna automatyzacja procesu wytwarzania, to musimy zaimplementować pierwszy jej etap – ciągłą integrację (Continuous Integration). Bez testów ani rusz.

Następnym nie mniej ważnym powodem jest produktywność deweloperów. Badania z 1993 roku przeprowadzone przez Jakoba Nielsena pokazują, że jeżeli testy trwają powyżej 1 sekundy, programiści tracą flow. Gdy trwają powyżej 10 sekund, tracą uwagę. Pracownicy pewnej korporacji zauważyli, że jeśli testy trwają powyżej 30 sekund, w ogóle ich nie puszczają na swojej maszynie – zlecają to serwerowi CI. Zatem produktywność programistów gwałtownie spada.

Rozwijając testy, warto przykładać uwagę, czy są odpowiednio zautomatyzowane – czy układają się w piramidę.

Najwięcej powinno być testów jednostkowych, których wykonanie trwa milisekundy. Następnie testy integracyjne, które mogą już zajmować więcej czasu, bo na przykład uderzają do zewnętrznych serwisów. Następnie automatyczne testy, które sprawdzają całą funkcjonalność od początku do końca, aż wreszcie, jeśli zachodzi taka potrzeba – testy manualne.

Oczywiście piramidy mogą być bardzo różne – jedne mogą być bardzo szerokie i niskie, drugie wąskie i spiczaste. Najważniejsze to obserwować trend w projekcie, aby niepostrzeżenie nie przejść do modelu lodów. Jest to antywzorzec strategii testowania, w którym dominuje testowanie manualne.

Czym?

Czyli wybór narzędzi. Ta decyzja wydaje się być najbardziej rozdmuchanym aspektem automatyzacji. Prawdopodobnie dlatego, że tak łatwo ją sprzedać. W sieci są miliony artykułów, rankingów, statystyk, recenzji. Najważniejsze to pamiętać, że narzędzie nie jest celem samym w sobie. Kluczowy jest produkt, a automatyzacja pozwala go sprawnie rozwijać.

W wyborze narzędzi warto posiłkować się wiedzą współpracowników – może ktoś już z danym narzędziem pracował, może w innym projekcie jest już używane. Wdrażając to samo rozwiązanie co koledzy w firmie, zyskujemy nie tylko wsparcie merytoryczne, ale też dodatkowy argument, gdyby okazał się potrzebny zakup płatnej subskrypcji.

Kolejnym kryterium, jakim można się kierować, jest swój obecny stan wiedzy – prawdopodobnie szybciej uda się nam wdrożyć nowe rozwiązania, używając narzędzia bazującego na wiedzy już przez nas posiadanej. Czyli na przykład, jeśli jesteśmy obeznani z pythonem, łatwiej przyjdzie nam się nauczyć narzędzia bazującego na nim.

Przed ostateczną decyzją warto dać sobie czas na testy – taki proof of concept danego narzędzia – czy naprawdę ma szanse spełniać pokładane przez nas w nim nadzieje?

Co do naszych ulubionych narzędzi, można się rozeznać po wpisach na blogu. Obecnych i przyszłych – zachęcamy do obserwowania ;)

Kiedy przestać?

Kiedy wszystko będzie się działo samo – automagicznie. Czyli prawdopodobnie nigdy. Zawsze będzie można coś poprawić, przyśpieszyć, uprościć.

W tym miejscu warto zaznaczyć, że automatyzacja wcale nie wyklucza udziału człowieka w danym procesie. Niektóre procesy mają wpisaną w swoją naturę taką interakcję. Zatem w potoku dostarczania oprogramowania możemy mieć fazę „potwierdzenie jakości rozwiązania”, w której to QA przegląda testy i uznaje je za wystarczające lub też przerywa dany potok.

A jakie Ty masz przemyślenia o automatyzacji? Czym się kierujesz przy wyborze tego, co automatyzować? Których narzędzi używasz? Dlaczego tych? Zachęcamy do komentowania :)

Zapowiedź

W kolejnym artykule napiszę o dobrych praktykach związanych z automatyzacją. Zwrócę uwagę między innymi na kontrolę wersji oraz istotność migracji na wyższe środowiska.