Boję się rano wstać… czyli o pracy developera

powrót do listy
Boję się rano wstać… czyli o pracy developera

"Boję się rano wstać, boję się dnia, codziennie rano boję się otworzyć oczy ze strachu przed świtem. Zupełnie nie wiem, co zrobić z nadchodzącym dniem... no nie mogę" - znany cytat z "Dnia Świra” nie musi dotyczyć nas samych. Przecież dzień może być pełen wyzwań, ciekawych ludzi i ciekawej pracy.

Autor:

Łukasz, Team Leader
Grzegorz,
Software Developer

Dzisiaj chciałem wam opowiedzieć, jak wygląda pisanie nowego mikroserwisu przy wykorzystaniu fajnych narzędzi programistycznych.

Załóżmy, że dzisiaj przychodzi do naszego zespołu Product Owner i opowiada o swojej wizji. Jednak wizja ta (tak czasem bywa) nie jest zrozumiała dla nas, developerow. Stwierdzamy więc: zróbmy sobie event storming, podczas którego postaramy się przenieść wizje (Product Ownera) w proces i wymagania. Po takim event stormingu jesteśmy w stanie utworzyć diagramy C4, tzn. przełożyć wymagania na konkretne komponenty w chmurze.

Rozmawiamy i decydujemy, czy pójdziemy w rozwiązania oparte na dockerze czy na lambdzie, czy zadania będą kolejkować się, czy będą płynnie przechodzić przez proces. Co do wszystkich niewiadomych, jeżeli chodzi o infrastrukturę, wykonujemy „Proof of concept”. Dzięki temu gromadzimy i uporządkowujemy sobie wszystkie informacje, niezbędne do podjęcia decyzji, których komponentów i serwisów powinniśmy użyć. Tę decyzję zaś umieszczamy w ADR czyli Architecture Decision Record.

Nie działamy w próżni

Jeśli jest coś niejasnego po stronie danych biznesowych, do akcji wkracza nasz analityk. Zaczyna szukać, analizować, pyta, co tak naprawdę jest do zrobienia i „z czym to się je”. Kiedy analityk ułoży sobie w głowie jakiś plan działania, tworzy user story na backlogu i zabiera się za testy akceptacyjne lub end to end. Wyzwanie jest tym większe, że testy dotyczą czegoś, co jeszcze nie istnieje!

W tym procesie wykorzystuje metodologię BDD, czyli Behavior Driven Development. W ogroooomnym uproszczeniu chodzi o testowanie całego produktu z punktu widzenia końcowego użytkownika i rzeczywistych czynności, które będzie wykonywał.

Staramy się, żeby każde zadanie miało opisane kryteria akceptacyjne oraz wycenę w punktach „story points”. Dzięki tym drugim możemy sprawdzić, czy nasz zespól jest w szczytowej formie, czy jeszcze trochę brakuje 😊

Kiedy już wiemy, jakiego narzędzia użyjemy z zasobów AWS, możemy wykorzystać terraform do napisania kodu. Ten za pomocą „kilku linijek kodu” będzie w stanie budować infrastrukturę niezależnie od środowiska, a kod infrastruktury będzie znajdował się w naszym repozytorium. Dodatkowo, każdy napisany już raz komponent będzie można używać w kolejnych serwisach.

Brzmi super?

To dopiero początek! Żeby taki terraformowy kod wykorzystywać w naszym świecie, używamy Jenkinsa, a dokładnie pipeline’y, które definiują, jak wystawić dane środowisko dla konkretnego serwisu. Co to znaczy? To, że za pomocą kodu Jenkinsa jesteśmy w stanie powiedzieć, jak ma wyglądać środowisko i z czego ma się składać. Możemy w samym pipeline określić, które komponenty będą wystawiane tylko na produkcji, a które tylko na środowiskach developerskich.

Skoro już wiemy jak będzie wyglądać nasza infrastruktura, to możemy spokojnie usiąść do kodu, ale… w czym go napiszemy?

Każdy mikroserwis ma odpowiednią specyfikę i zastosowanie, więc warto się zastanowić. W większości przypadków wybieramy sprawdzonego .Net Core, ale mamy kilka serwisów opartych o NodeJS czy Pythona. Jednocześnie, aby zagwarantować niezawodność kodu, piszemy testy jednostkowe oraz testy integracyjne. Generalnie robimy wszystko, co trzeba, by zapewnić, że wszystko będzie działać zgodnie z oczekiwaniami.

Gdy mamy już kod, trzeba z niego zbudować paczkę, a może kilka paczek, a może dockera? Można by też automatycznie sprawdzić testy integracyjne, wydajnościowe…

a może przeprowadzić statyczną analizę kodu? Hm…

A czemu by tak nie zrobić wszystkiego w jednym prostym narzędziu TeamCity? Tam takie rzeczy robi się przyjemnie i szybko. W samym TeamCity można działać na 2 sposoby:

  • wszystkie pipeline’y wyklikać z GUI i zapisać w repozytorium albo
  • wszystkie pipeline’y pisać w kodzie Kotlina.

Jedno i drugie rozwiązanie daje nam możliwość przywrócenia pipeline’ów do stanu z repozytorium. Wprawdzie wierzymy, że nasze serwisy działają, ale w tym momencie wiara to za mało, więc dodatkowo zaprzęgliśmy Pagerduty, który zawiadamia, kiedy na produkcji wystąpiła jakaś niebezpieczna sytuacja. Przy każdym serwisie dbamy również o to, by monitoring i szukanie w logach było proste i przyjemne. Takie możliwości dają Kibana Newrelic.

Ale to… już?

Tak to z pomocą wszystkich wymienionych narzędzi i przy zaangażowaniu całego zespołu dotrwaliśmy do końca procesu, a Ty do końca jego opisu 😊 Tak ja to widzę, i to…

I Tobie takich historii z happy-endem życzę😊

Poprzedni artykuł

Metapack z nagrodami na eCommerce Awards 2020!

przeczytaj

Następny artykuł

Summer Academy 2020 w nowej odsłonie

przeczytaj