Dlaczego poprawne CI/CD jest ważne od samego początku projektu

Po co w ogóle CI/CD

Obecnie dostarczanie projektu powinno opierać się na poprawnie skonstruowanym procesie CI/CD. Największym benefitem takiego podejścia, będzie zdecydowanie możliwość dostarczania nowych funkcjonalności w bardzo krótkim czasie. Cały proces CI/CD pozwala na skrócenie czasu, od wrzucenia kodu na repozytorium, do opublikowania nowej wersji aplikacji, dla końcowego klienta. Powinien być to proces w pełni zautomatyzowany, co odciąża developera od żmudnego procesu aktualizacji oprogramowania. Zamiast “marnować” ten czas, może więcej wyprodukować nowych funkcji i szybciej dostarczyć wartość do klientów.

Poprawne CI/CD I zyski z niego płynące

Cały proces budowania aplikacji i jej dostarczania powinien być ściśle związany z sposobem jaki pracujemy. Tak na prawdę powinien wyznaczać ramy w jakich pracujemy. Współgrając z nim wytworzony kod będzie najwyższej jakości. Poniżej wypisałem przykładowe kroki poprawnego pipeline z opisem zalet, które zyskujemy podczas poprawnego zaimplementowania każdego z nich:  

• Automatyczne uruchomienie testów jednostkowych. Pierwsza warstwa sprawdzenia, czy kod aplikacji przechodzi pozytywnie testy logiki. Uruchamiane są one przy każdym budowaniu aplikacji, co pozwala wykryć w bardzo wczesnej fazie podstawowe błędy. 
• Automatyczne uruchomienie testów integracyjnych. Kolejna warstwa sprawdza, czy dostarczona aplikacja działa z zewnętrznym oprogramowaniem, takim jak 3rd party API czy baza danych. Dzięki temu mamy pewność, że połączenia aplikacji są stabilne i działają poprawnie. 
• Automatyczny skaner podatności. Zewnętrzne narzędzie takie jak na przykład SonarQube, sprawdza czy napisany kod nie jest podatny na luki bezpieczeństwa. W przypadku obrazów dockerowych warto uruchomić trivy scan, tak aby sprawdzić czy obraz nie zawiera kluczowych luk bezpieczeństwa. 
• Wersjonowanie. W przypadku paczek czy obrazów, można dodać krok który będzie podbijał wersje paczki. 

Wszyskie powyższe kroki bez poprawnego procesu, programista musiałby wykonać sam. Są to procesy powtarzalne, dzięki czemu można odciążyć developera i w pełni to zautomatyzować. Największa zaletą całego rozwiązania jest znalazienie potencjalnego błędu przed dotarciem do środowiska produkcyjnego. Jest to bardzo ważna rzecz, gdyż każdy błąd znaleziony na środowisku wyżej, kosztuje nieporównywalnie więcej do naprawienia. Szybki fix na środowisku developerskim nie kosztuje praktycznie nic, a hotfix na produkcji potrafi generować bardzo dużo problemów.

Początek projektu

Początek projektu jest bardzo ważny. W tym artykule całkowicie ominę proces, w którym to biznes zbiera wymagania i planuje budźet. Jeśli chodzi, o czysto techncizny start projektu, możemy zacząć go na kilka sposobów. Według mnie, najlepszym sposobem jest wpuszczenie DevOpsa (lub kogoś kto ma doświadczenie w procesach CI/CD). Wtedy, często po konsultacji z architektem, można wypracować najlepsze podejście do prowadzenie projektu.

Ważne jest to, aby dobrze rozpisać jak ma wyglądać workflow w gicie i zasetupować pierwsze pipeline. Następnie warto zacząć tworzyć pełny proces dostarczania kodu, tak aby pierwsi programiści, którzy zasilą projekt, mogli dostarczać kod na repozytorium, który będzie automatycznie deployowany na środowiska.

Co jednak gdy nie ma dostępnego DevOpsa?

Warto wtedy wyznaczyć jednego developera, który za pomocą architekta i zasięgając artykułow dostępnych w internecie, powinien wyznaczyć kierunek, w którym cały projekt będzie się poruszał. Dostępne są bardzo przejrzyste tutoriale, które pokazują jak dobrze dobrać proces CI/CD do wybranych technologii. Wtedy poświecając czas jednego programisty, na pewno odzyskamy go z nawiązką. Do tego cały zespół będzie pracował lepiej i bardzo efektywnie.

Na początku klepmy funkcjonalności, a DevOps zrobi robotę później

Pracująć w kilku projektach, spotkałem się z podejściem, że najpierw robimy aplikację, a dopiero potem DevOps przyjdzie i posprząta wszystkie manualne procesy i je w pełni zautomatyzuje. Moim zdaniem, jest to bardzo złe podejście. Finalnie, osoba która będzie automatyzować procesy, będzie miała dużo gorszą pracę. Jeśli repozytorium jest nieprzystosowane do CI/CD, bardzo dużo pracy pójdzie na samo dostosowywanie infrastruktury. Jest to marnowanie czasu, gdyż na początku dobrze stworzone i przemyślane repozytorium, dostarczy nam wszystkich narzędzi do stworzenia solidnego procesu.

Warto przekonywać klienta, że płacąc więcej na początku za coś, czego tak na prawdę nie widać (pipeline itd.) - dużo oszczędzi. Każda firma dąży teraz do tego, aby dostarczać nowe funkcje, nie kilka razy do roku, a przynajmniej kilka razy w tygodniu czy miesiącu.

Poprawne CI/CD we własnych side-projektach

Pisząc ten artykuł chcę też wspomnieć o side-projektach, a nie tylko tym czym zajmujemy się w firmach czy korporacjach. Moim zdaniem, jeśli sami robimy bloga, aplikacje czy cokolwiek innego, warto skorzystać chociażby z OOTB CI/CD, które znajdziemy w popularnych repozytoriach kodu. Dla przykłądu taki GitHub udostępnia bardzo przydatne narzędzie, jakim jest GitHub Actions. Jeśli chodzi o konkurencję, polecam również Gitlab CI/CD oraz Azure DevOps. Za pomocą wszystkich wspomnianych narzędzi, zyskamy prostę i bardzo pomocne CI/CD w projekcie.

Podsumowanie

Uważam, że początek projektu bardzo oddziałuje, na cały jego przebieg. Robiąc to mądrze, zwiększamy szansę na powodzenie całości. Warto zawsze przekonać klienta, aby zaczynał projekty tak jak opisałem, gdyż finalnie będzie na pewno, bardziej zadowolony z współpracy z nami czy firmą. Budując poprawne CI/CD kształtujemy bardzo nowoczesne podejście, które oprócz profesjonalnego prowadzenia, dostarcza nam również wartość w postaci szybszego dostarczania nowych featerów na produkcję w przyszłosći.