Testowanie aplikacji i systemów - CONTINUOS INTEGRATION I DELIVERY w procesie wytwarzania oprogramowania

1. Systemy informatyczne są wykorzystywane w różnych dziedzinach, a automatyzacja jest kluczem do optymalizacji pracy. W przypadku programistów narzędziem usprawniającym tworzenie oprogramowania są procesy Continuous Integration i Continuous Delivery, które wraz z Continuous Deployment stanowią elementy metodyki DevOps i mają na celu automatyzację procesu integracji i dostarczania działających wersji oprogramowania.

2. Chociaż pojęcia Continuous Integration (CI) i Continuous Delivery (CD) często występują razem, nie są tożsame i mogą być mylone. CI kojarzone jest z programowaniem, a CD z zadaniem administratora. W rzeczywistości są to kolejne etapy procesu tworzenia oprogramowania, obejmujące nie tylko kodowanie, ale także przeniesienie aplikacji do środowiska testowego i dostarczenie działającej aplikacji klientowi.

3. Continuous Integration (CI) to automatyczne buildowanie programu na serwerze po każdym commicie. Ta praktyka DevOps pozwala na szybkie wykrycie błędów i konfliktów. Programista powinien stale integrować zmiany w kodzie ze zmianami wprowadzanymi przez innych członków zespołu. Przy wykorzystaniu repozytorium GIT, automatyczna integracja rozpoczyna się po podaniu komendy „git push”. Następnie na serwerze następuje zautomatyzowany proces buildowania aplikacji i uruchamiany jest zestaw testów, których zadaniem jest potwierdzenie poprawności wprowadzonych zmian.

4. Jeśli integracja w Continuous Integration (CI) nie powiedzie się, wprowadzone zmiany wymagają naprawy. Nowe funkcje i zmiany powinny być dodawane tylko do działającego programu. Proces integracji można podzielić na trzy fazy: Push - wysłanie zmian na serwer, Test - lokalizacja błędów, i Fix - naprawa wykrytych problemów.

5. Continuous Delivery (CD) to kolejny krok w automatyzacji produkcji oprogramowania, następujący po pozytywnym przejściu fazy testów. Polega na automatycznym dostarczaniu działającej wersji programu do ostatniego środowiska przed produkcją. CD poprzedza Continuous Deployment, czyli ciągłe wdrażanie na produkcję. Do produkcji powinny trafiać tylko w pełni funkcjonujące wersje aplikacji, stąd konieczność sprawdzenia jej na wcześniejszych etapach.

6. Continuous Integration (CI) i Continuous Delivery (CD) wymagają ciągłego przeprowadzania testów (Continuous Testing, CT), aby dostarczyć wysokiej jakości aplikację i kod do użytkownika końcowego. CT to zbiór automatycznie przeprowadzanych testów, np. wydajnościowych czy regresji, będący częścią procesu CI/CD. Pomimo wielu korzyści, praktyki CI/CD nie zawsze są rozwiązaniem, które należy wdrażać we wszystkich przypadkach.

7. Praktyka Continuous Integration (CI) nakazuje, aby developerzy wysyłali swój kod do repozytorium wersji często, np. raz dziennie. Ułatwia to identyfikację błędów i problemów jakościowych kodu. Zespoły stosujące CI wdrażają także mechanizmy okresowego testowania kodu i wdrażania poprawek. Istnieją różne techniki kontrolowania, jakie zmiany trafiają na produkcję, np. „version-control branching” z wybraną strategią wprowadzania i łączenia zmian do poszczególnych etapów pracy nad projektem. Taka praktyka działa wyśmienicie, ale może być problematyczna, gdy wielu developerów pracuje równolegle nad wieloma rzeczami.

8. Inne techniki zarządzania zmianami to np. „feature flag”, czyli przełącznik, który pozwala na włączanie/wyłączanie danej funkcjonalności w kodzie głównym. Większość narzędzi CI/CD pozwala na uruchomienie procesu tworzenia „paczki” (build) na kilka sposobów, np. ręcznie, automatycznie po commicie lub w zdefiniowanym czasie. Wybór sposobu zależy od projektu i zespołu. Najlepszą praktyką jest wysyłanie częstych commitów, co pozwala na osiągnięcie krótkiego czasu tworzenia paczki.

9. Zespoły programistyczne często wykorzystują frameworki do projektowania, tworzenia i wykonywania testów automatycznych, w tym testów regresji, aby utrzymać wysoką jakość produktu. Testy te pozwalają na sprawdzenie, czy aplikacja działa poprawnie. Najlepszą praktyką jest umożliwienie przeprowadzenia testów regresji przez developerów w lokalnym środowisku przed commitem zmian. Testy regresji to tylko początek - inne testy, np. wydajności, API, bezpieczeństwa, również mogą zostać zautomatyzowane. Kluczowe jest umożliwienie uruchomienia testu za pośrednictwem CLI, webhook lub usługi sieciowej.

10. Większość projektów opiera się na dwóch środowiskach - produkcyjnym i testowym, ale duże projekty mogą mieć więcej środowisk. Continuous Delivery (CD) wprowadza automatyzację procesu wysyłania zmian na te środowiska. Typowy CD pipeline zawiera kroki takie jak:

• pobranie kodu z repozytorium, uruchomienie build'a
• przeniesienie kodu na wybrane środowisko
• zarządzanie zmiennymi środowiskowymi
• przeniesienie komponentów aplikacji do odpowiadających im usług
• wykonanie restartów usług
• wykonanie testów i cofnięcie zmian w przypadku błędów oraz zwrócenie wyników
• udostępnienie logów zdarzeń.

11. W pipeline Continuous Integration/Continuous Delivery (CI/CD) mogą być włączone dodatkowe procesy, np. synchronizacja danych, archiwizacja, kopie zapasowe, wdrożenie zmian w aplikacji. Wiele zespołów implementuje rozwiązania CI/CD w chmurze przy wykorzystaniu konteneryzacji, np. Docker lub Kubernetes. Ważne jest, aby wszystkie zmienne środowiskowe były skonfigurowane poza aplikacją, a narzędzia pozwalały na ustawienie zmiennych, maskowanie haseł i kluczy dostępowych oraz integrację z repozytorium kodu i zadaniami. Ważny jest także dostęp do raportów i przyjazny widok zbiorczy (dashboard), umożliwiający łatwą kontrolę procesu wysyłania zmian i reakcji na problemy.

12. CI/CD to najlepsza praktyka devops, ponieważ rozwiązuje problem między programistami a administratorami serwerów. Jest to idealne rozwiązanie dla firm, które chcą często wprowadzać zmiany w aplikacji. Automatyzacja etapów dostarczania zmian w kodzie i testów ułatwia i przyspiesza proces wysyłania zmian na środowisko produkcyjne. Zespoły operacyjne widzą większą stabilność dzięki standardowym konfiguracjom, testom, oddzieleniu zmiennych środowiskowych / systemowych od aplikacji i zautomatyzowanym procedurom cofania zmian. Wdrożenie procesu CI/CD wymaga współpracy zespołów programistycznych i administracyjnych przy wyborze odpowiednich schematów pracy, narzędzi i technologii. Nakład pracy włożony we wdrożenie tych rozwiązań szybko się zwraca dzięki standaryzacji pracy, minimalizacji błędów, zwiększeniu szybkości reakcji itp. Jakość tworzonego kodu i bezpieczeństwo całej aplikacji znacząco się zwiększa. 

13. Zalety continous integration i continous delivery:

• firmy korzystające z CI/CD są w stanie szybko wdrożyć aplikację
• kod sprawdza się sam, bez konieczności manualnego wyzwalania tego procesu
• kod wdrożony na produkcje przynosi zyski w przeciwieństwie do kodu czekającego na manualną weryfikację, która jest procesem czasochłonnym