3 powody, dla których Twój proces CI/CD leży

Ręczne klikanie to nie automatyzacja

W jednej z firm logistycznych, którą wspieraliśmy w listopadzie 2023 roku, proces budowania paczki trwał aż 38 minut. Przez ten czas dwa główne procesory serwera CI były obciążone w 94%, a trzej programiści pili kawę, czekając na wynik. Okazało się, że ich skrypty co chwilę pobierały te same 2.4 GB bibliotek od nowa, zamiast korzystać z gotowego cache'u. To nie jest wydajność, to jest cyfrowy bałagan, który kosztuje firmę około 12 roboczogodzin w każdym tygodniu pracy przy zaledwie 5-osobowym zespole deweloperskim.

Jeśli Twój senior dev musi spędzać 45 minut każdego wtorku na ręcznym czyszczeniu cache'u na serwerze albo ręcznym kopiowaniu plików przez FTP, to znaczy, że palisz pieniądze. Widzieliśmy to u 23 naszych klientów w ostatnim roku. Mieli proces, który nazywali automatycznym, ale i tak wymagał on 'pilnowania' przez człowieka. Prawdziwy proces CI/CD musi działać tak, żebyś mógł o nim zapomnieć. Kod musi zarabiać, a nie sypać błędami tylko dlatego, że ktoś zapomniał kliknąć jeden przycisk w panelu zarządzania.

Kod musi zarabiać, a nie sypać błędami. Jeśli musisz 'pilnować' wdrożenia, to znaczy, że proces nie działa.

Testy, które nic nie sprawdzają

Szczerze: testy manualne to dziś strata czasu, szczególnie gdy powtarzasz te same czynności przy każdym mniejszym wdrożeniu. Jeden z naszych klientów z branży e-commerce posiadał 67 scenariuszy testowych, które pracownik QA musiał przeklikać ręcznie przed każdą aktualizacją o 14:00. Zajmowało to ponad 4 godziny. Automatyzacja zaledwie 12 kluczowych ścieżek zakupu skróciła ten czas do 6 minut i 15 sekund. Dzięki temu zespół mógł skupić się na szukaniu poważnych luk, a nie na sprawdzaniu, czy formularz kontaktowy się wysyła.

Często spotykamy się z sytuacją, gdzie firma chwali się 'pokryciem kodu na poziomie 79%', ale testy sprawdzają tylko błahe funkcje, które i tak nigdy się nie psują. W marcu 2024 pracowaliśmy z software housem, gdzie testy przechodziły na zielono, a aplikacja i tak wywalała się na produkcji przy próbie płatności. Powód był prosty: nikt nie testował integracji z bramką płatniczą, bo 'było to zbyt trudne do ustawienia'. Ustawiamy procesy, które działają same i faktycznie wyłapują błędy tam, gdzie one realnie występują.

Szczerze: testy manualne to dziś strata czasu. Skup się na automatyzacji ścieżek, które przynoszą Ci pieniądze.

Środowiska, które ze sobą nie rozmawiają

Słynne zdanie 'u mnie działa' to najczęstszy objaw leżącego procesu CI/CD. Wynika to zazwyczaj z różnic między komputerem dewelopera a serwerem produkcyjnym. W lipcu 2024 naprawialiśmy system, w którym wersja bazy danych u programisty różniła się o jedną małą poprawkę od tej na serwerze. To wystarczyło, żeby 7% zapytań kończyło się błędem po wdrożeniu nowej funkcji. Deweloper stracił 6 godzin na szukanie błędu w kodzie, podczas gdy problem leżał w konfiguracji systemu.

Bez zbędnych prezentacji — samo mięso: jeśli nie używasz dockeryzacji albo innych metod izolacji środowiska, Twój proces zawsze będzie ryzykowny. W TyeVals stawiamy na to, żeby serwer testowy był lustrzanym odbiciem produkcji. Dzięki temu unikasz stresu w środy o 14:00. Widzieliśmy firmy, które po ujednoliceniu środowisk zmniejszyły liczbę szybkich poprawek (hotfixów) o 31% w ciągu zaledwie dwóch miesięcy od wprowadzenia zmian w konfiguracji.

Jak to naprawić w 3 krokach?

Pierwszy krok to zawsze audyt tego, co aktualnie macie. Nie musicie od razu kupować drogich narzędzi. Często wystarczy zmiana 5 linii w pliku konfiguracyjnym GitLaba czy GitHub Actions, żeby build przyspieszył o połowę. W jednym przypadku usunięcie niepotrzebnych kroków z rurociągu zaoszczędziło firmie 450 dolarów miesięcznie na fakturze od dostawcy chmury. To są realne oszczędności, które widać w Excelu już po 30 dniach od wdrożenia zmian.

Krok drugi to priorytetyzacja testów. Nie automatyzuj wszystkiego naraz. Zacznij od tego, co psuje się najczęściej. Jeśli co miesiąc macie problem z logowaniem, to niech to będzie pierwszy test automatyczny. Trzeci krok to edukacja zespołu. Narzędzia same kodu nie napiszą i testów nie puszczą, jeśli ludzie nie będą wiedzieli, po co to robią. Nasze konsultacje trwają zazwyczaj od 3 do 5 tygodni i kończą się konkretnym planem, który deweloperzy mogą wdrażać od ręki, bez czytania 100-stronicowych instrukcji.

Zacznij od naprawy tego, co najczęściej psuje Twój budżet. Automatyzacja musi się po prostu opłacać.