Jak mówi stare chińskie przysłowie – ludzie dzielą się na tych, którzy robią kopie zapasowe i tych, którzy jeszcze ich nie robą. Na szczęście programiści są dosyć świadomą grupą społeczną jeśli chodzi o utratę wszelkiego rodzaju danych, dlatego wymyślili system kontroli wersji. Wymyślili także, że rzeczy, które są powtarzalne trzeba automatyzować. Z połączenia tych i wielu innych czynności związanych rozwojem oprogramowania powstał termin DevOps – i właśnie o nim opowiem w dzisiejszym poście.
Czym jest DevOps?
Przede wszystkim jest to termin, który bardzo często pojawia się w projektach informatycznych, i żeby dać lepszy obraz tego, co się pod nim kryje, opiszę pewną sytuację.
Wyobraź sobie, że jesteś programistą. Twoim głównym zadaniem jest pisanie kodu, prawda? Tak jest w idealnym świecie, jednak do developmentu często dochodzą różne inne rzeczy, takie jak rozpisywanie zadań, liczne wdrożenia, spotkania i, oczywiście, testowanie kodu. DevOps to zbiór wszystkich praktyk, które umożliwiają sprawne prowadzenie projektu, zapewnienie wysokiej jakości rozwiązania, a także ciągłe, i najlepiej zautomatyzowane, wdrożenia. Aby te wszystkie elementy okiełznać powstało nawet specjalne narzędzie, które nazywa się Azure DevOps. Opiszę go dokładnie poniżej, ale już teraz wspomnę, że dzięki niemu możemy nie tylko zarządzać zadaniami, wersjonować kod, automatycznie budować i wdrażać nasze projekty ale także uruchamiać testy.
Jako deweloper powiem, że często rzeczy związane z prowadzeniem projektu nie są najprzyjemniejszą jego częścią. Czasami wręcz nie chce nam się rozpisywać i wyceniać (czyli definiować w jakim czasie zrobimy zadanie) każdego, nawet najdrobniejszego zadania. Tym bardziej nikomu nie chce się opisywać każdej funkcjonalności, bo przecież łatwiej opowiedzieć o tym w dwóch słowach koledze, niż pisać długi wywód. Natomiast z punktu widzenia całego projektu znacznie upraszcza to działanie i monitorowanie postępu, a także pozwala eliminować błędy ludzkie.
Dobra organizacja zadań
Obecnie bardzo popularne są metodyki zwinne, takie jak Scrum,. Generalnie wspomagają one prowadzenie projektu – w miarę równomiernie rozkładają zadania na członków zespołu, a także pozwalają zorientować się, co dzieje się w projekcie. W założeniu każdy członek zespołu scrumowego powinien być w stanie wykonać każde zadanie, co jest dużym plusem. Teoretyczna sytuacja, że ktoś jest zawalony robotą, a druga osoba nie może przejąć jego zadań, nie zdarza się. W praktyce – dobrze jeśli zespół jest właśnie na tyle dojrzały, że każda z należących do niego osób, może wykonać większość zadań. Oczywiście często jest tak, że ktoś specjalizuje się w jakimś obszarze, ale w podbramkowej sytuacji, po przekazaniu wiedzy, zadanie powinno zostać wykonane.
Warto też zwrócić uwagę na rozpisywanie zadań. Istnieje wiele narzędzi, w których można budować backlog, czyli taką listę zadań do zrobienia. Każdy z zespołu może „przypiąć” zadanie do siebie i aktualizować postęp w pracach przy nim. Dzięki temu każdy wie, na czym stoi.
Wersjonowanie kodu
Systemy kontroli wersji, o których wspomniałem na początku, są niezwykle istotne jeżeli pracujemy w większym zespole. Czym jest wersjonowanie? Wyobraź sobie sytuację, że piszesz procedury do transformacji ETL. Po pewnym czasie okazuje się, że procedura zawiera błąd, wprowadzasz więc poprawkę, nadpisujesz kod i wdrażasz. Po miesiącu klient mówi, że jednak poprzednie rozwiązanie było dobre i czy nie można go przywrócić. I tutaj pojawia się cała kwintesencja wersjonowania kodu – jeśli tego nie robiłeś, to nie możesz przywrócić starej wersji.
Wersjonowanie polega na tym, aby wszystkie zmiany, które zostały wykonane, były odkładane. No ale w jaki sposób mamy odkładać wszystko, co zrobiliśmy? Otóż są do tego specjalne narzędzia – na przykład GIT. Dzięki temu wystarczy, że zapiszesz nową wersję pliku, a historyczna zostanie odłożona, do Ciebie należy tylko zapisanie pliku. Możesz przeglądać każdą wersję, pierwszą, drugą czy setną, wszystko odkłada się automatycznie i zawsze można do tego wrócić. Oczywiście uprościłem samą ideę, GIT potrafi o wiele, wiele więcej, ale na ten moment tyle nam wystarczy.
Automatyzacja procesu wdrożenia
Proces wytwarzania oprogramowania wygląda zwykle tak, że mamy do dyspozycji 3 środowiska – deweloperskie, testowe i produkcyjne.
To pierwsze ,jak sama nazwa wskazuje, służy do rozwijania nowych funkcjonalności. Drugie powinno być jak najbardziej zbliżone do produkcji, aby umożliwić testowanie nowych funkcjonalności. Natomiast produkcja to środowisko, które przede wszystkim musi działać bardzo stabilne i nie powinno się bez uzasadnionej konieczności wykonywać żadnych zmian w jego strukturze. W takim razie, jeśli rozwijamy nową funkcjonalność, powinniśmy ją w jakiś sposób przenieść ze środowiska deweloperskiego na testowe, a następnie na produkcję. W jaki sposób to zrobić?
Możemy oczywiście zrobić to ręcznie, czyli wszystkie nowe rzeczy przekopiować na kolejne środowiska. Niestety takie działania często mogą być obarczone błędem ludzkim, czasami możemy po prostu zapomnieć o jakiejś istotnej rzeczy i system przestanie działać. Druga sprawa to powtarzalność czynności. Nie ma sensu przenosić rozwiązania dwa razy, skoro możemy zrobić automat, który przeniesie rozwiązanie bez naszej ingerencji. A możemy? Tak! Azure DevOps umożliwia utworzenie przepływów CI/CD do przenoszenia rozwiązania między środowiskami. Oczywiście nie jest tak, że zautomatyzujemy absolutnie wszystko i każde wdrożenie będziemy robić w piątek po południu 🙂 Ale znacząco może nam to ułatwić pracę. Tworzenie pipelinów nie jest skomplikowane, ale są elementy, które trzeba obsłużyć w nieco bardziej skomplikowany sposób.
Testowanie
Jest to nieodłączny element każdego systemu, a przynajmniej powinien być 🙂 Testy dzielimy na te manualne i automatyczne. Testy manualne to takie, w których ktoś, kto ma odpowiednią wiedzę biznesową sprawdza, czy dane w systemie są poprawne. Takie testowanie jest szczególnie istotne w przypadku miar kalkulowanych ze skomplikowaną logiką. Często ktoś z „biznesu” bardzo szybko wyłapie wyjątki, które zostały pominięte w analizie. Deweloperzy bardzo często nie znają typowych wartości poszczególnych wskaźników, przez co nie mogą zweryfikować czy na przykład jakiś KPI nie ma wartości absurdalnie wielkich. Niestety, takie testy są dość pracochłonne, a druga sprawa jest taka, że często ludzie, którzy mają tak dużą wiedzę biznesową zwyczajnie nie mają czasu zajmować się jeszcze czymś dodatkowym.
Dlatego warto przyglądać się jak testowany jest nasz system i próbować automatyzować przypadki testowe. Testy automatyczne zwykle polegają na porównaniu dwóch wartości, bądź sprawdzeniu, czy mieszczą się one w granicach normy. Takie rozwiązanie ma znaczną przewagę nad poprzednim. Może być uruchamiane przez każdego dewelopera, który otrzymuje prostą informację czy rozwiązanie działa poprawnie, czy nie. Czas trwania takiego testu jest też znacznie krótszy.
Praca z Azure DevOps
Wszystkie te 4 elementy łączy w sobie usługa Azure DevOps. Z poziomu portalu możemy wersjonować kod, tworzyć nowe zadania dla deweloperów, budować przepływy CI/CD, a także uruchamiać przypadki testowe. Fakt, że wszystko jest w jednym miejscu jest bardzo istotny, dzięki temu bez problemu możemy przypisywać taski, do konkretnych commitów, a podczas wdrożeń, mamy wylistowane wszystkie zmiany jakie wejdą.
Aby lepiej zobrazować jak wygląda praca z Azure DevOps, nagrałem krótki film, w którym bardziej szczegółowo opowiadam o pracy z tym narzędziem. Zachęcam do obejrzenia!