← Wszystkie tematy W 60% ogłoszeń · 28 z 47 ogłoszeń frontend React

CI/CD

Taśma w fabryce zabawek

CI/CD jest w 28 z 47 ogłoszeń. Od frontendowca oczekuje się, że wie, co pipeline sprawdza i jak go przyspieszyć, a nie tylko, że „jest Jenkins”.

Przerobione Opanowane 0 z 3 pytań

Ucz się z Claude Wytłumacz od zera Próbna rozmowa Zadanie praktyczne Ściąga na 1 stronę

Co piszą w ogłoszeniach

„Współpraca w zespole zwinnym oraz udział w procesach CI/CD i wdrażania aplikacji.”
Upvanta sp. z o.o. · Front-End Engineer (React / TypeScript / AWS)
„praktyczna znajomość GitLab CI oraz narzędzi analizy kodu w CI – minimum 1 rok doświadczenia lub 3 projekty”
Randlab · React Developer – (K/M/N)
„Understanding of CI/CD pipelines, containerisation, and automated deployment processes.”
Capco Poland · Front-End Engineer - React (Payments)

Scena · pipeline

Taśma w fabryce zabawek

Każda zmiana w kodzie to nowa zabawka. Zanim trafi do sklepu, jedzie po taśmie i mija kolejne stanowiska: ktoś sprawdza, czy jest ładnie złożona, czy części pasują, czy działa. Jeśli coś jest nie tak, taśma staje, a zepsuta zabawka nigdy nie trafia do dzieci. Wybierz, co zepsuć, i puść taśmę.

Lintporządek w kodzie
Typytsc --noEmit
Testyvitest, RTL
Buildvite build
Podglądpreview URL
Sklepprodukcja

Sklep (produkcja) wersja 12 działa

Co zepsuć?

Wybierz usterkę i puść taśmę.

Porównajmy

Ręcznie czy na taśmie?

	Ręczne wdrażanie	CI/CD
Kto sprawdza?	Ten, kto pamięta.Testy lokalnie „u mnie działa”.	Taśma, za każdym razem tak samo.Pipeline na każdy PR: lint, typecheck, testy, build.
Co, gdy coś pęknie?	Dowiadują się dzieci w sklepie.Błąd na produkcji.	Taśma staje przed sklepem.Blokada merge (required checks, branch protection).
Jak zobaczyć przed wydaniem?	Nijak, albo jeden wspólny serwer testowy.Kolejka do stagingu.	Każda zabawka ma swoją wystawę.Preview deployment na każdy PR (Vercel, Netlify, własny).
Jak szybko?	Raz na tydzień, duże paczki.Duże, ryzykowne wydania.	Często i małymi kawałkami.Cache zależności, równoległe joby, testy tylko zmienionych paczek.
Coś przeszło i psuje?	Gorączkowe łatanie.Hotfix pod presją.	Przycisk „cofnij” albo wyłączenie funkcji.Rollback do poprzedniego artefaktu, feature flags, canary release.

Taśma

Każda zmiana jedzie tą samą drogą i mija te same kontrole.

Wystawa

Każda zabawka ma swój podgląd, zanim trafi do sklepu.

Wstecz

Gdy coś jednak przejdzie, jednym przyciskiem wracasz do poprzedniej zabawki.

Sprawdź się

Pytania z rozmów

Najpierw odpowiedz na głos, dopiero potem rozwiń odpowiedź.

Co powinien robić pipeline dla aplikacji frontendowej przy każdym PR-ze?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Zabawka mija stanowiska po kolei: czy ładnie złożona, czy części pasują, czy działa, czy da się zapakować. Dopiero wtedy trafia na wystawę.

Na rozmowę: Instalacja z lockfile (npm ci), lint i formatowanie, typecheck (tsc --noEmit), testy jednostkowe i komponentowe, build produkcyjny, opcjonalnie budżet rozmiaru bundla i Lighthouse CI, testy E2E na kluczowych ścieżkach, preview deployment z linkiem w PR. Wszystkie kroki jako required checks w branch protection, więc nie da się zmergować na czerwono.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające

Jak przyspieszyć pipeline? (cache, równoległe joby, testy tylko zmienionych paczek)

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Kilka taśm obok siebie, a stanowisko, które już sprawdziło taką samą część, nie sprawdza jej drugi raz.

Na rozmowę: Cache zależności (actions/cache, cache node_modules / pnpm store) i cache wyników buildów (Turborepo / Nx remote cache). Równoległe joby: lint, typecheck i testy niezależnie, sharding testów E2E. W monorepo tylko projekty dotknięte zmianą (nx affected, turbo --filter). Do tego szybsze narzędzia (Vitest, esbuild/SWC) i anulowanie poprzednich runów tego samego PR-a (concurrency).

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające
Jak wycofać złe wdrożenie? Co to feature flags i preview deployments?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Gdy zabawka w sklepie okaże się zepsuta, jednym przyciskiem stawiasz z powrotem poprzednią. Feature flag to wyłącznik, który chowa nową część zabawki bez jej wymiany.

Na rozmowę: Rollback: każdy build to niezmienny artefakt z wersją, więc cofnięcie to przepięcie na poprzedni (Vercel/Netlify instant rollback, poprzedni obraz Dockera, poprzedni folder na CDN). Feature flags (LaunchDarkly, Unleash, własne) oddzielają wdrożenie od włączenia funkcji: kod jest na produkcji, ale włączony dla 5% albo dla testerów, i można go wyłączyć bez deployu. Preview deployment to osobny URL dla każdego PR-a do review przez QA i projektantów.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające

Poziom wyżej

Wersja dla seniora

Tak wyglądają pytania na seniora i leada: nie ma jednej dobrej odpowiedzi, liczy się to, jak ważysz kompromisy i czy mówisz o skali, ryzyku i ludziach.

Przypadek 1

Pipeline monorepo trwa 40 minut

Monorepo ma 25 projektów (aplikacje i paczki). Każdy PR uruchamia lint, testy i build wszystkiego, co trwa 40 minut. Programiści łączą zmiany w duże PR-y, żeby rzadziej czekać, co zwiększa ryzyko.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy znasz affected i cache zadań
Czy umiesz zmierzyć, gdzie ucieka czas
Czy myślisz o wpływie na sposób pracy zespołu

Odpowiedź seniora

Najpierw pomiar: czas każdego joba i kroku, co jest powtarzane i co czeka na co. Potem trzy zmiany. Uruchamianie tylko dotkniętych projektów (nx affected, turbo run --filter=...[origin/main]) na podstawie grafu zależności. Zdalny cache wyników zadań (Nx Cloud, Turborepo Remote Cache albo własny), więc niezmienione paczki nie budują się drugi raz. Równoległość: lint, typecheck i testy jako osobne joby, sharding testów E2E.

Do tego szybsze narzędzia (Vitest zamiast Jest, SWC lub esbuild), cache zależności (pnpm store) i concurrency z cancel-in-progress dla nowych pushy w tym samym PR. Pełny pipeline zostaje na main i nocą.

Cel: mediana poniżej 10 minut, śledzona na dashboardzie. Efekt uboczny, o który chodzi: mniejsze PR-y i częstsze wdrożenia.

Typowe wpadki

Wyłączenie testów, żeby było szybciej
Większe maszyny jako jedyne rozwiązanie
Affected bez poprawnego grafu zależności, przez co nie testujemy tego, co trzeba

Dopytają o

Co zrobisz, gdy cache da błędny wynik?
Jak traktujesz zmiany w plikach globalnych (lockfile, tsconfig)?
Jak zmierzysz wpływ na produktywność?

Zapytaj Claude Rozwiń case Zagraj interviewera

Przypadek 2

Bezpieczne wdrożenie zmiany, która dotyka danych

Nowa wersja zmienia format danych zapisywanych w localStorage i strukturę zamówienia wysyłaną do API. Poprzednia podobna zmiana zepsuła koszyk połowie użytkowników, a rollback nie pomógł, bo dane były już przepisane.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy rozumiesz, że rollback kodu nie cofa danych
Czy znasz wzorce expand/contract i kompatybilność wstecz
Czy umiesz stopniować ryzyko (canary, flagi)

Odpowiedź seniora

Zasada: każda wersja musi umieć czytać dane zapisane przez poprzednią i następną. Stosuję expand/contract: najpierw wdrażam wersję, która czyta stary i nowy format, ale zapisuje stary. Potem włączam zapis nowego formatu flagą. Na końcu, gdy nikt nie używa starego, usuwam jego obsługę. Dane w localStorage mają pole version i migrację przy odczycie.

Po stronie API ten sam porządek: backend najpierw akceptuje oba formaty, dopiero potem frontend wysyła nowy. Wdrożenie przez canary (5% ruchu, potem 25%, 100%) z automatycznym monitoringiem błędów i konwersji koszyka. Flaga pozwala wyłączyć zmianę bez deployu.

Rollback jest wtedy bezpieczny, bo stara wersja rozumie nowe dane albo nowych danych jeszcze nie ma. Plan wdrożenia z kryteriami przejścia i cofnięcia zapisuję w PR.

Typowe wpadki

Zakładanie, że rollback rozwiązuje każdy problem
Jednoczesna zmiana frontu i backendu w jednym wdrożeniu
Migracja danych bez wersji

Dopytają o

Jak długo utrzymujesz obsługę starego formatu?
Jakie metryki zatrzymują canary automatycznie?
Co z użytkownikami z otwartą starą wersją aplikacji?

Zapytaj Claude Rozwiń case Zagraj interviewera

Przypadek 3

Niestabilne testy blokują merge kilka razy dziennie

W CI około 8% przebiegów pada przez testy, które po ponownym uruchomieniu przechodzą. Zespół przyzwyczaił się do klikania „Re-run”, a prawdziwe błędy czasem przechodzą niezauważone.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy traktujesz flaky testy jako problem systemowy, nie indywidualny
Czy znasz metody wykrywania i kwarantanny
Czy pilnujesz, żeby nie stracić ochrony

Odpowiedź seniora

Najpierw dane: raporty JUnit z każdego przebiegu do narzędzia, które liczy niestabilność testów (np. wbudowane w Buildkite, Datadog CI, Currents, albo własny skrypt). Lista testów z najwyższym odsetkiem losowych porażek i ich właścicielami.

Proces: test, który przekroczy próg niestabilności, trafia automatycznie do kwarantanny (uruchamia się, ale nie blokuje merge) z ticketem dla zespołu i terminem. Retry ustawiam najwyżej na 1 i raportuję testy, które przeszły dopiero za drugim razem, zamiast je ukrywać.

Naprawa przyczyn: brak izolacji danych, zależność od czasu i kolejności, sztywne timeouty, prawdziwe usługi zewnętrzne, za mało zasobów. Cel: odsetek flaky poniżej 1% i powrót testów z kwarantanny w ciągu sprintu.

Typowe wpadki

Globalne retry 3 razy, żeby było zielono
Usuwanie niestabilnych testów bez zastąpienia
Brak właściciela dla testów

Dopytają o

Jak odróżnić flaky test od flaky aplikacji?
Ile testów może być jednocześnie w kwarantannie?
Jak przekonasz zespół, że to warte czasu?

Zapytaj Claude Rozwiń case Zagraj interviewera