Automatyzacja: wprowadzenie

Cześć!

Dzisiejsze IT staje przed wyzwaniem automatyzacji powtarzalnych procesów. Nigdy nie zdarzyło Ci się budować projektu, kopiować paczki na serwer, a następnie ręcznie przeklikać, czy wszystko działa prawidłowo? Nigdy nie wkleiłeś produkcyjnych kluczy do kodu przed wrzuceniem aplikacji do sklepu? W takim razie ten wpis nie jest dla Ciebie, jednorożocu Ty! W przeciwnym wypadku, zapraszam.

Upierdliwe życie programisty

Pracowałem kiedyś nad dużym oprogramowaniem. Monolitem, takim pisanym przez 100 - 500 osób. Wiesz, kilkanaście środowisk, z czego 2 używane etc. Jak w każdym projekcie w 2010’s, mieliśmy serwer, który budował projekt. Jakaś mądra głowa pochyliła się nad tematem i stwierdziła, że musi być. W końcu automatyzacja to szybszy feedback i mniejsze koszty, bierzemy! Był tylko jeden problem - zbudowanie całego projektu trwało kilka godzin.

Dodatkowo, samo zbudowanie wszystkiego nie oznaczało, że oprogramowanie nadaje się do wdrożenia. W końcu moduł mógł się zbudować, ale nie być podpięty pod resztę projektu (sic!). Zamiast skupić się na rozwijaniu oprogramowania, każdy programista musiał kontrolować, czy konfiguracja jest poprawna. Drobne rzeczy są łatwe do przeoczenia. Z tego powodu soft często się wykładał z niejasnych przyczyn.

Mniejsza skala, te same problemy

Zejdźmy jednak w tej chwili na ziemię. Nie każdy projekt jest tak opasły. Co nie znaczy, że problemy są inne. Prześledźmy taki przypadek. Tworzysz projekt w kilka osób. Wdrożenia projektu może dokonać tylko przedstawiciel klienta. Polityka bezpieczeństwa albo inny korporacyjny szit, zdarza się. W związku z tym, wszystkie hasła muszą zostać podmienione przez osobę wykonującą deploy. Przy okazji, człowiek ten ulega pokusie “poprawienia” kilku rzeczy w konfiguracji, według swojego widzimisię. W ten sposób otrzymujesz niespójny i zmodyfikowany produkt, za który odpowiadasz.

Lokalne podwórko

Mam bloga na statycznym CMSie. Każda zmiana na stronie wiąże się ze zbudowaniem HTMLi, styli etc. Pliki wypycham w dwa miejsca: FTP z Azure Web App oraz Azure Blob Storage. Za każdym razem muszę mieć osobną paczkę do wrzucenia w każde z miejsc. Dodatkowo mam dwa różne pliki Web.config - jeden dla serwera testowego i drugi dla produkcji (produkcja ma HTTPS z HSTS). Ręczne dobranie plików, które dostaję z Jekylla, zbudowanie LESSów, podzielenie na FTP i Bloba i wrzucenie na serwer zajmuje jakieś 10 minut i nie mam pewności, że wszystko jest na miejscu.

Dlaczego automatyzować?

Wymienione sytuacje różnią się poziomem złożoności. Można jednak wyodrębnić z nich kilka powodów, dla których należy przeprowadzić automatyzację procesu:

• rozwój oprogramowania wymaga coraz większej liczby ręcznie konfigurowanych elementów,
• każdy nowy element jest kolejnym, możliwym do popełnienia, błędem… błędem który, prędzej czy później, wreszcie popełnisz,
• ludzie są słabi w powtarzaniu czynności, w przeciwieństwie do komputerów,
• skrypt automatyzujący jest dla projektu tym, czym testy uczące dla kodu,
• automatyzacja może zastapić dokumentację konfigurowania projektu, która jest zwykle nieaktualna lub nikt jej nie czyta.

Czym automatyzować?

Możliwości automatyzacji są bardzo szerokie. Popularne są dedykowane narzędzia automatyzujące, budujące oraz task runnery. Tego typu narzędzia mogą polegać na uruchamianiu kolejnych komend z powłoki (jak ma to miejsce w Make), lub stosować dedykowane API (Grunt.js, Gulp.js, MSBuild). Mogą operować na kolejnych artefaktach w systemie plików lub przetwarzać wszystko w pamięci za pomocą strumieni.

Innymi możliwościami są:

• skrypty powłoki systemowej, (bash, pliki bat),
• skrypty lub programy napisane w dowolnych językach programowania (C#, Python, Ruby),
• oprogramowanie uruchamiające skrypty cyklicznie (cron).

Metoda jest w rzeczywistości dowolna. Liczy się łatwość osiągnięcia celu, łatwość uruchomienia skryptu/programu oraz łatwość utrzymywania przez zespół. Zupełnie jak z każdym innym programem.

Kiedy i jak automatyzować?

O automatyzacji należy zacząć myśleć w momencie, gdy jakaś powtarzalna czynność staje się uciążliwa lub wymaga przypominania sobie całego procesu. Takie sytuacje są powszechne. Pamiętaj jednak, że program automatyzujący jest tak samo podatny na błędy, jak każdy inny software. Zbędna automatyzacja może skończyć się w następujący sposób:

Jeśli jednak automatyzacja się opłaci, należy przetestować skrypt przed wykorzystaniem go w systemie produkcyjnym. Jak to zrobić? Przede wszystkim, należy odseparować konfigurację (ścieżki do katalogów, hasła, klucze) od właściwego kodu. Następnie trzeba zmodyfikować konfigurację w taki sposób, aby nie łączyła się w żaden sposób z produkcją lub nie narobiła bałaganu w przypadku jakiegoś babola.