13 postów z tagiem "GitHub Actions"

Ukończyłem LFD140 „GitHub for Open Standards Development" od The Linux Foundation. Kurs uczy, jak przenieść zasady grupy roboczej do repozytorium: kto zatwierdza zmianę normatywną, którą gałęzią idzie specyfikacja do ratyfikacji, gdzie zapisać sprzeciw i jak wymusić to ochroną gałęzi i CI. Ten model uważam za dobry i wart przeniesienia także poza fundacje open source. Przykładowe bramki GitHub Actions z materiałów kursu uruchomiłem jednak lokalnie, na odtworzonym checkoucie pull requesta. Z pięciu skryptów żaden nie działa poprawnie w podanej postaci. Dwie kontrole CHANGELOG przepuszczają zmianę w specyfikacji bez wpisu, dwie bramki blokują PR-y, które powinny przejść, a krok sprawdzający etykietę przechodzi zawsze. Próg „dwóch zatwierdzeń" liczy recenzje zamiast recenzentów. Poniżej opisuję, co z kursu warto wziąć, co w przykładach nie działa i jak wyglądają poprawione wersje.

Magento 2 (obecnie Adobe Commerce) to potężna, modularna platforma e-commerce. Ze względu na swoją architekturę – zaawansowany backend oparty na strukturze EAV oraz dynamiczny frontend wykorzystujący biblioteki takie jak Knockout.js i jQuery – platforma ta stawia przed inżynierami jakości (QA) specyficzne i bardzo wymagające wyzwania.

Standardowe podejścia do testowania automatycznego często zawodzą w zderzeniu z Magento 2. Poniżej przedstawiamy szczegółową analizę największych wyzwań testowych specyficznych dla tej platformy oraz sprawdzone wzorce radzenia sobie z nimi.

Witamy w wielkim finale naszej serii! Przez ostatnie tygodnie budowaliśmy Piramidę Testów, walczyliśmy z asynchronicznością, przejmowaliśmy kontrolę nad bazą danych i API, pilnowaliśmy dostępności i bawiliśmy się w hakerów.

Jednak wszystkie te niesamowite testy, bez względu na to jak czysty jest ich kod, nie mają znaczenia, dopóki działają wyłącznie na komputerze dewelopera. Prawdziwa jakość rodzi się w Continuous Integration (CI/CD).

W tej części przyjrzymy się infrastrukturze i sposobom wpinania automatyzacji tak, by stanowiła twardą bramkę jakościową (Quality Gate).

Po ustabilizowaniu fundamentów strategii testowej i zapanowaniu nad środowiskiem (sieć oraz dane), czas spojrzeć na warstwę, z którą nasz użytkownik styka się bezpośrednio – interfejs.

W trzeciej części cyklu skupimy się na połączonych konceptach Testowania Wielopłaszczyznowego (Cross-X) oraz Testowania Wizualnego. Dlaczego warto o nich mówić razem? Ponieważ oba skupiają się na zagwarantowaniu, że niezależnie od urządzenia, silnika czy najmniejszej zmiany w CSS, nasza aplikacja wygląda i zachowuje się wzorowo.

W poprzedniej części cyklu o automatyzacji testów omówiliśmy fundamenty: Piramidę Testów i traktowanie testów jako pełnoprawnego kodu produkcyjnego (Page Object Model, TypeScript). Jednak nawet najlepiej napisany kod testowy będzie bezużyteczny, jeśli będzie działał na niestabilnym środowisku z nieprzewidywalnymi danymi.

Dlatego w tym bardzo "mięsistym" technicznie wpisie skupimy się na wyzwaniu, które spędza sen z powiek wielu testerom: Izolacja Danych i Zarządzanie Ruchem Sieciowym.

Zanim zaczniemy pisać o konkretnych narzędziach, konfigurować pipeline'y CI/CD i uruchamiać testy w środowiskach wirtualnych, musimy odpowiednio ustawić nasz "mindset". Budowanie stabilnego frameworka testowego zaczyna się od obranej strategii (Piramidy Testów), a kończy na uświadomieniu sobie kluczowej zasady: kod testów to kod produkcyjny.

W dzisiejszym świecie tworzenia oprogramowania (szczególnie aplikacji Fullstack), testowanie to nie tylko "dodatek", ale absolutny fundament utrzymania zdrowego cyklu życia projektu. W projekcie reads od początku postawiliśmy na wysoką jakość i zautomatyzowane procesy. Chciałbym podzielić się z Wami, dlaczego wybraliśmy Playwrighta do testów End-to-End (E2E), jak to narzędzie sprawdza się w praktyce oraz w jaki sposób wpięliśmy je w naszą "piramidę testów" na CI/CD.

Jako inżynier bezpieczeństwa, który zaczynał od analizy pakietów w Wiresharku i ręcznego „fuzzowania” formularzy, z pewnym sentymentem wspominam rok 2005. Wtedy bezpieczeństwo aplikacji webowych opierało się na naiwnym zaufaniu do protokołów GET i POST. Parametry w URL-u były dosłownie zaproszeniem do przejęcia bazy danych (SQLi), a brak walidacji po stronie serwera był normą, nie wyjątkiem. Królowała era monolitycznych systemów, w których jedna luka w kodzie oznaczała natychmiastowe RCE (Remote Code Execution). Zamiast podejścia Secure by Design, żyliśmy w świecie „perymetrycznej obrony”, wierząc, że firewall ochroni nas przed wszystkim.

Mam VPS z kilkoma usługami dockerowymi: WireGuard, Pi-hole, n8n, SonarQube, środowisko staging dla mojego projektu. Przez długi czas jedynym "monitoringiem" było SSH i docker ps. Postanowiłem to zmienić.

Ten wpis to kopalnia wiedzy z mojego wdrożenia — dowiesz się z niego, jak poprawnie skonfigurować cały stack i jak poradzić sobie z wyzwaniami, które mogą pojawić się w nowoczesnych środowiskach Docker (jak Ubuntu 24.04). To nie jest zwykły tutorial "kopiuj-wklej", ale praktyczny przewodnik po tym, jak sprawić, by monitoring na VPS naprawdę działał.

Jako programiści często wpadamy w pułapkę dokładania kolejnych narzędzi i skanerów do naszych pipeline'ów w CI/CD, nie zważając na to, jak mocno wydłuża to czas trwania całego procesu. Chcemy mieć zrobiony linting, przetestowany kod (zarówno jednostkowo, jak i E2E), jakość potwierdzoną przez SonarQube i wreszcie bezpieczeństwo obrazów Dockerowych za pomocą Trivy.