CI/CD dla małego zespołu — od czego zacząć automatyzację wdrożeń

W wielu małych zespołach wdrożenie wygląda tak samo od lat: ktoś loguje się na serwer, pobiera kod, uruchamia kilka poleceń z pamięci i ma nadzieję, że nic nie pominął. Działa to do dnia, w którym tej osoby nie ma, polecenia się zmieniły albo pośpiech sprawił, że wdrożono niewłaściwą gałąź. Automatyzacja nie wymaga dużego zespołu ani rozbudowanej infrastruktury — w najprostszej formie to kilkadziesiąt linii konfiguracji, które zwracają się już przy pierwszym uniknięciu błędu.

Autor: zespół Convert Studio — software house z Kielc i Krakowa, projektujemy aplikacje webowe, sklepy i wdrożenia AI dla firm.

Co to daje małemu zespołowi

Automatyzacja bywa kojarzona z dużymi organizacjami, które wdrażają dziesiątki razy dziennie. Tymczasem mały zespół zyskuje na niej proporcjonalnie więcej, bo każda osoba jest tam na wagę złota, a każdy błąd we wdrożeniu zatrzymuje pracę całości.

• Wdrożenie przestaje zależeć od jednej osoby. Proces jest opisany w kodzie, nie w czyjejś pamięci.
• Błędy wychodzą przed produkcją. Test, który nie przeszedł, zatrzymuje zmianę, zanim dotrze do klientów.
• Mniejsze zmiany, częściej. Łatwiej ustalić, co zepsuło system, gdy zmiana obejmuje trzy pliki, a nie trzy tygodnie pracy.
• Szybki powrót. Wycofanie wersji jest jednym poleceniem, a nie nocną akcją ratunkową.
• Mniej stresu. Wdrożenie w piątek przestaje być ryzykiem, gdy proces jest powtarzalny i odwracalny.

Etapy dojrzewania procesu

Nie trzeba robić wszystkiego naraz. Każdy z poniższych etapów przynosi korzyść samodzielnie i przygotowuje grunt pod następny.

Większości małych zespołów wystarczają etapy od pierwszego do czwartego. Piąty ma sens przy systemach, których przerwa w działaniu realnie kosztuje.

Co sprawdzać automatycznie

Kontrole uruchamiane przy każdej zmianie powinny być szybkie — zespół, który czeka pół godziny na wynik, zacznie je omijać.

• Budowanie aplikacji. Najprostsza kontrola i zaskakująco często wychwytująca błędy — brakujący plik, literówkę w imporcie.
• Testy automatyczne. Nawet niewielki zestaw obejmujący kluczowe ścieżki daje realną ochronę. Szerzej o tym w materiale o testach automatycznych.
• Analiza statyczna. Sprawdzenie typów i stylu kodu, wychwytujące klasę błędów bez uruchamiania aplikacji.
• Skan zależności pod kątem znanych podatności bezpieczeństwa.
• Migracje bazy danych uruchomione na świeżej bazie — czy da się je wykonać od początku.

Układ środowisk

Mały zespół nie potrzebuje pięciu środowisk. Potrzebuje dwóch dobrze utrzymanych i jasnych zasad, co gdzie trafia.

• Środowisko testowe — automatycznie aktualizowane po każdym scaleniu do gałęzi głównej. Możliwie wierna kopia produkcji: ta sama wersja bazy, te same ustawienia serwera, zanonimizowane dane.
• Produkcja — aktualizowana świadomym zatwierdzeniem, zawsze z wersji, która wcześniej działała na środowisku testowym.

Kluczowa zasada: na produkcję trafia dokładnie ten sam zbudowany pakiet, który był sprawdzany na środowisku testowym — a nie kod zbudowany ponownie. Ponowne budowanie potrafi dać inny wynik, na przykład przez zmianę wersji zależności w międzyczasie.

Sekrety i konfiguracja

Automatyzacja wymaga dostępu do serwerów, baz danych i usług zewnętrznych. Sposób przechowywania tych danych przesądza o bezpieczeństwie całego procesu.

• Nigdy w repozytorium. Hasło zatwierdzone raz w historii pozostaje w niej na zawsze, nawet po usunięciu z bieżącej wersji.
• W magazynie sekretów systemu automatyzacji, niewidocznym w dziennikach.
• Osobne dla każdego środowiska — środowisko testowe nie ma dostępu do bazy produkcyjnej.
• Najmniejsze możliwe uprawnienia dla konta wdrożeniowego.
• Możliwość wymiany bez przebudowy procesu.

Migracje bazy danych — najtrudniejsza część

Kod da się wycofać jednym poleceniem. Zmianę struktury bazy — już nie zawsze. Usunięta kolumna nie wróci po wycofaniu wersji aplikacji.

Bezpieczny wzorzec rozkłada zmiany niszczące na dwa wdrożenia. Najpierw dodajesz nową kolumnę i kod, który pisze do obu. Po upewnieniu się, że wszystko działa, w kolejnym wdrożeniu usuwasz starą. Dzięki temu w każdym momencie da się wrócić do poprzedniej wersji aplikacji bez utraty danych.

Przed każdą migracją zmieniającą dane warto też upewnić się, że istnieje świeża kopia zapasowa — opisaliśmy to w materiale o planie odtwarzania.

Wycofanie wersji

Proces jest tak dobry, jak szybko pozwala wrócić do stanu sprzed zmiany. Warto to przećwiczyć, zanim będzie potrzebne.

• Poprzednia wersja gotowa do uruchomienia bez ponownego budowania.
• Jedno polecenie wycofujące wdrożenie, opisane i przetestowane.
• Migracje odwracalne albo rozłożone tak, żeby stary kod działał z nową strukturą.
• Obserwacja metryk po wdrożeniu — o czym piszemy w materiale o monitoringu aplikacji.

Najczęstsze błędy

• Automatyzacja wszystkiego naraz. Projekt trwa miesiącami i zostaje porzucony. Lepiej zacząć od skryptu wdrożenia.
• Kontrole zbyt wolne. Zespół zaczyna scalać zmiany bez czekania na wynik.
• Środowisko testowe odbiegające od produkcji. Błąd nie występuje przy testach, bo środowisko jest inne.
• Ręczne poprawki na produkcji. Zmiana wprowadzona bezpośrednio na serwerze zostanie nadpisana przy następnym wdrożeniu.
• Brak właściciela procesu. Konfiguracja, której nikt nie utrzymuje, psuje się przy pierwszej zmianie narzędzi.

Najczęstsze błędy przy wdrażaniu CI/CD

Automatyzacja potrafi rozczarować, jeśli zespół popełni kilka typowych błędów. Większość z nich wynika z próby zrobienia wszystkiego naraz albo z traktowania procesu jako jednorazowej konfiguracji.

• Zbyt wolny proces. Gdy sprawdzenie zmiany trwa kilkadziesiąt minut, programiści zaczynają łączyć wiele zmian w jedną, co odbiera sens częstej integracji. Warto regularnie mierzyć czas i usuwać najwolniejsze kroki.
• Niestabilne testy. Test, który czasem przechodzi, a czasem nie, uczy zespół ignorowania czerwonego wyniku. Takie testy trzeba naprawiać lub tymczasowo wyłączać od razu.
• Sekrety zapisane w repozytorium. Hasła i klucze powinny trafiać do procesu przez mechanizm zmiennych chronionych, nigdy przez pliki w kodzie.
• Brak ścieżki wycofania. Automatyczne wdrożenie bez prostego sposobu powrotu do poprzedniej wersji zamienia każdy błąd w incydent.
• Różnice między środowiskami. Jeśli testy działają w innym środowisku niż produkcja, zielony wynik niewiele znaczy. Kontenery pomagają utrzymać zgodność.
• Jedna osoba rozumiejąca konfigurację. Plik opisujący proces powinien być czytelny i omówiony z całym zespołem.

Dobrym nawykiem jest traktowanie konfiguracji procesu jak zwykłego kodu: zmiany przez przegląd, krótkie komentarze przy nieoczywistych krokach i porządkowanie tego, co przestało być potrzebne.

Plan na pierwszy tydzień

Zespół, który dopiero zaczyna, nie musi budować całego procesu od razu. Rozsądny plan mieści się w kilku dniach pracy rozłożonych na tydzień.

• Dzień pierwszy — uruchomienie automatycznej kompilacji i sprawdzenia składni przy każdej zmianie.
• Dzień drugi — dołączenie istniejących testów, nawet jeśli jest ich niewiele.
• Dzień trzeci — automatyczne wdrożenie na środowisko testowe po scaleniu zmian.
• Dzień czwarty — spisanie i sprawdzenie procedury wycofania wersji.
• Dzień piąty — wdrożenie produkcyjne uruchamiane jednym przyciskiem, z powiadomieniem zespołu.

Po takim tygodniu proces nie jest doskonały, ale już działa i zdejmuje z zespołu najbardziej żmudne, ręczne kroki. Kolejne usprawnienia dodaje się wtedy, gdy pojawia się konkretna potrzeba.

Najważniejsze, żeby po tym tygodniu cały zespół rozumiał, co dzieje się z kodem od momentu zapisania zmiany do jej pojawienia się na produkcji, i wiedział, co zrobić, gdy któryś krok zakończy się błędem.

Podsumowanie

CI/CD nie jest luksusem dużych zespołów. W małym zespole automatyzacja wdrożeń chroni przed zależnością od jednej osoby, wychwytuje błędy przed produkcją i zamienia wdrożenie ze stresującego rytuału w powtarzalną operację. Nie wymaga też rozbudowanej infrastruktury — każdy etap przynosi korzyść samodzielnie.

Zacznij od najprostszego kroku: zapisz wszystkie polecenia, które dziś wykonujesz ręcznie przy wdrożeniu, w jednym skrypcie i uruchom go przy kolejnym wydaniu. Już to eliminuje najczęstszy błąd — pominięty krok. Następnie dodaj automatyczne uruchamianie testów przy każdej zmianie. Więcej o budowie utrzymywalnych systemów przeczytasz na stronie aplikacje webowe.