Google PCD: Testowanie, inżynieria jakości oraz zarządzanie bezpiecznymi wdrożeniami — Przewodnik do nauki

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Część Google Professional Cloud Developer — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Google, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Zespoły o wysokiej dynamice pracy w Google Cloud łączą rygorystyczne testowanie z progresywnym dostarczaniem, aby zmniejszyć ryzyko, jednocześnie przyspieszając wprowadzanie zmian. Solidna strategia obejmuje testy od jednostkowych po end-to-end, realistyczne dane i symulację zależności, zautomatyzowane bramki jakości oraz kontrolowane wzorce wdrożeń, takie jak canary i blue-green. Obserwowalność, odpowiedzialność i zdyscyplinowana weryfikacja po wdrożeniu zamykają pętlę. Ta sekcja szczegółowo opisuje, jak projektować pod kątem niezawodności, izolować ryzyko i bezpiecznie promować buildy między środowiskami za pomocą usług Google Cloud.

Strategia testowania i zarządzanie danymi

Piramida testów i typy testów

Testy jednostkowe: Szybka, izolowana weryfikacja funkcji, klas i małych modułów. Powinny one dominować w zestawie testów. Uruchamiaj je przy każdym commicie i pull requeście.
Testy integracyjne: Weryfikują interakcje między komponentami, takimi jak aplikacja i jej magazyn danych lub kolejka. Używaj emulatorów Google Cloud, jeśli są dostępne.
Testy kontraktowe: Kontrakty sterowane przez konsumenta (consumer-driven contracts) dla mikrousług zapobiegają wprowadzaniu łamiących zmian w API. Weryfikuj zachowanie dostawcy (provider) względem oczekiwanej przez konsumenta schemy i semantyki przed integracją. Używaj narzędzi takich jak Pact; wersjonuj swoje API i publikuj schematy.
Testy end-to-end: Sprawdzają całą ścieżkę systemu, używając konfiguracji, tożsamości i polityk sieciowych zbliżonych do produkcyjnych. Ogranicz ich liczbę, zrównoleglaj i uruchamiaj na środowiskach przedprodukcyjnych (pre-prod).
Testy dymne (smoke tests): Minimalne sondy potwierdzające, że krytyczne zależności, trasy i kontrole stanu (health checks) działają poprawnie po każdym wdrożeniu. To Twoja pierwsza weryfikacja po wdrożeniu.

Zarządzanie danymi testowymi, izolacja, powtarzalność i parzystość środowisk

Zasilanie danymi (data seeding): Generuj małe, deterministyczne zbiory danych dla testów jednostkowych i większe, reprezentatywne zbiory dla testów integracyjnych/wydajnościowych. Zasilaj dane z fixtures zapisanych w kontroli wersji.
Izolacja: Upewnij się, że testy nie współdzielą stanu. Używaj efemerycznych baz danych, izolowanych przestrzeni nazw (namespaces) w GKE i unikalnych prefiksów dla obiektów w Cloud Storage. Dla SQL twórz schematy per test; dla Pub/Sub generuj tymczasowe tematy/subskrypcje.
Powtarzalność: Przypinaj wersje zależności, twórz hermetyczne buildy i ustalaj stałe ziarna losowości (random seeds). Przechowuj kontenery testowe z ich skrótami (digests) w Artifact Registry.
Parzystość środowisk: Standaryzuj obrazy kontenerów i infrastrukturę jako kod (IaC) na wszystkich środowiskach: deweloperskim (dev), QA, stagingowym i produkcyjnym. Trzymaj konfigurację poza obrazami i używaj metadanych oraz sekretów specyficznych dla danego środowiska. Dla Compute Engine przechowuj wartości dla danego wdrożenia w metadanych szablonu instancji; dla parzystości między projektami skonfiguruj klucz metadanych środowiska i odczytuj go przy starcie, aby wybrać konfigurację specyficzną dla środowiska.

Mockowanie, emulatory, atrapy (fakes) i usługi piaskownicy (sandbox)

Mocki/stuby: Zastępuj kolaborantów na poziomie jednostkowym, aby izolować logikę i eliminować wywołania sieciowe. Unikaj nadmiernego mockowania; asercje wykonuj na zachowaniu, a nie na szczegółach implementacji.
Emulatory: Preferuj oficjalne emulatory do testów integracyjnych. Przykłady: emulatory Firestore/Datastore, Pub/Sub, Spanner i Bigtable. Zapewniają one wierność API bez opłat chmurowych i przyspieszają CI.
Atrapy (fakes): Gdy emulator nie istnieje, uruchamiaj lekkie, lokalne atrapy (np. atrapę magazynu obiektów) lub współdzielone usługi piaskownicy (sandbox) z silną izolacją i limitami (quotas).
Symulacja zależności zewnętrznych: Dla API firm trzecich uruchamiaj atrapy oparte na kontraktach za service mesh lub bramką API; konfiguruj timeouty, ponowienia (retries) i wstrzykiwanie chaosu (chaos injection), aby testować obsługę błędów.

Typowe tryby awarii i kompromisy

Zbytnie poleganie na testach end-to-end spowalnia iteracje; zainwestuj w testy jednostkowe i kontraktowe, aby wyłapywać problemy wcześniej.
Współdzielone, długo działające środowiska testowe akumulują dryf konfiguracyjny i zanieczyszczenie danych. Preferuj środowiska efemeryczne oraz idempotentne procesy konfiguracji i czyszczenia (setup/teardown).
Emulatory mogą nie odzwierciedlać idealnie środowiska produkcyjnego. Używaj testów E2E na środowisku stagingowym z prawdziwymi usługami przed promocją na produkcję.

Krótki przykład Cloud Build do oddzielania etapów kończących się niepowodzeniem

steps:
- name: gcr.io/cloud-builders/gcloud
  entrypoint: bash
  args: ['-c', 'make compile && make unit']
- name: gcr.io/cloud-builders/gcloud
  entrypoint: bash
  args: ['-c', 'docker build -t $IMAGE .']
- name: gcr.io/cloud-builders/gcloud
  entrypoint: bash
  args: ['-c', 'make integration']  # run against emulators or ephemeral env
images: ['$IMAGE']

Oddzielne kroki zapewniają, że historia builda precyzyjnie wskaże, czy niepowodzeniem zakończyła się kompilacja/testy jednostkowe, budowanie czy integracja.

Testy niefunkcjonalne i jakość kodu

Testy wydajnościowe

Typy: Testy obciążeniowe (stan ustalony), przeciążeniowe (ponad szczytowe obciążenie), nasiąkowe (długotrwałe) i pojemnościowe.
Narzędzia: Używaj Cloud Monitoring do SLO i alertów, Cloud Trace do analizy opóźnień i Cloud Profiler do wskazywania gorących ścieżek (hot paths). Dla GKE skaluj za pomocą Cluster Autoscaler i HPA; dla workerów Pub/Sub, HPA oparte na metrykach zewnętrznych obsługuje skalowanie w odpowiedzi na skoki obciążenia.
Testowanie na produkcji: Używaj wdrożeń typu dark launch i dublowania ruchu (request mirroring), aby bezpiecznie oceniać nowe backendy przy użyciu ruchu produkcyjnego. External HTTP(S) Load Balancing wspiera dublowanie ruchu; Anthos Service Mesh wspiera traffic shadowing.

Testy bezpieczeństwa

SAST/skanowanie sekretów: Uruchamiaj statyczne analizatory w CI i odrzucaj zahardkodowane dane uwierzytelniające. Przechowuj sekrety w Secret Manager z dostępem opartym na zasadzie najmniejszych uprawnień (least-privilege).
Skanowanie zależności i obrazów: Włącz Container Analysis w Artifact Registry. Wymuszaj polityki za pomocą Binary Authorization, wymagając atestacji potwierdzających brak krytycznych podatności przed wdrożeniem.
DAST: Skanuj środowiska stagingowe za pomocą uwierzytelnionych skanerów i blokuj wydania w przypadku znalezienia krytycznych podatności.

Dostępność i regresja

Dostępność: Zintegruj zautomatyzowane testy dostępności (a11y), na przykład Lighthouse CI, jako nieblokujące sprawdzenia przed mergem; naprawiaj problemy przed wydaniem.
Zestawy testów regresji: Utrzymuj starannie dobrane, stabilne zestawy testów regresji dla krytycznych ścieżek użytkownika. Uruchamiaj testy dymne przy każdym wdrożeniu, a pełną regresję na kandydatach do wydania (release candidates).

Analiza statyczna, bramki jakości i przegląd kodu (code review)

Analiza statyczna: Skonfiguruj lintery i formatery odpowiednie dla danego języka jako sprawdzenia przed zatwierdzeniem (pre-submit checks). Użyj Bazel lub podobnego narzędzia do zrównoleglenia.
Bramki jakości: Przerywaj buildy w przypadku przekroczenia progów (pokrycie kodu testami, złożoność, błędy lintera). Publikuj wyniki w logach Cloud Build.
Przegląd kodu (code review): Wymagaj przeglądu przez dwie osoby dla ryzykownych zmian, pliku CODEOWNERS dla krytycznych ścieżek oraz CI przed zatwierdzeniem (presubmit CI) na tagach używanych do wydań.
Łańcuch dostaw: Generuj SBOM, podpisuj artefakty i przechowuj ich pochodzenie (provenance). Wymuszaj sprawdzanie atestacji w Binary Authorization.

Stopniowe dostarczanie i bezpieczne wdrożenia

Strategie wdrażania

Rolling (kroczące): Stopniowa wymiana podów lub instancji. Niskie ryzyko dla usług bezstanowych; łącz z sondami gotowości (readiness probes) i ustawieniami dotyczącymi nadmiarowych zasobów (surge) oraz dostępności.
Blue-green: Uruchom kompletne nowe środowisko, przeprowadź weryfikację, a następnie przełącz ruch. Umożliwia natychmiastowy rollback poprzez przywrócenie poprzedniej konfiguracji load balancera. Idealne, gdy potrzebujesz natychmiastowej możliwości wycofania zmian.
Canary: Stopniowo przenoś niewielki procent ruchu na nową wersję, obserwując kluczowe metryki. Zautomatyzuj promocję do pełnego wdrożenia, jeśli system jest stabilny; wycofaj zmiany (rollback) w przypadku regresji.
Dzielenie ruchu (traffic splitting): Kieruj ruchem na podstawie procentu lub atrybutów (nagłówki, ciasteczka, user-agent) za pomocą GKE z Anthos Service Mesh lub użyj wbudowanego dzielenia ruchu w Cloud Run i App Engine.

Flagi funkcyjne i eksperymentowanie

Flagi funkcyjne (feature flags): Oddziel wdrożenie (deploy) od wydania (release). Używaj flag do stopniowego udostępniania funkcji, jako wyłączniki bezpieczeństwa (kill switches) i do przełączania eksperymentów. Przechowuj je centralnie (np. w zarządzanej usłudze do flag lub w magazynie konfiguracji chronionym przez IAM). Utrzymuj krótki cykl życia flag i usuwaj te niepotrzebne.
Ciche wdrożenia (dark launches): Wdrażaj funkcje jako wyłączone; waliduj je przy użyciu wewnętrznych użytkowników lub ruchu syntetycznego.
Ruch w tle (shadow traffic): Kopiuj żądania produkcyjne do nowych usług bez wpływu na użytkowników; porównuj odpowiedzi, aby wykryć regresje.
Kontrolowane eksperymenty: Implementuj routing A/B lub wielowymiarowy za pomocą reguł service mesh. W przypadku eksperymentów opartych na user-agent, kieruj ruchem na podstawie dopasowania nagłówka.

Bramki, zatwierdzenia, rollback i obserwowalność

Bramki wdrożeniowe (deployment gates): Dodaj testy integracyjne przed wdrożeniem oraz testy dymne/sprawdzające stan (smoke/health checks) po wdrożeniu. Do promocji między środowiskami używaj wyzwalaczy opartych na tagach, aby oddzielić budowanie od wydania.
Ręczne zatwierdzenia: Wymagaj zatwierdzenia przez człowieka na kluczowych etapach, takich jak przejście ze środowiska testowego (staging) na produkcyjne. Cloud Deploy wspiera kroki ręcznego zatwierdzania dla każdego celu (target).
Automatyczny rollback: Zdefiniuj SLO i polityki alertów; gdy wdrożenie canary naruszy progi błędów lub opóźnień, automatycznie wycofaj zmiany, wywołując API wdrożeniowe. Dbaj o to, by proces rollbacku był szybki i przećwiczony.
Obserwowalność wydań: Instrumentuj wydania, dodając etykiety z wersją do metryk i logów. Eksportuj metryki Prometheus do Cloud Monitoring i twórz metryki oparte na logach dla wzorców błędów, aby efektywnie kosztowo korelować dane telemetryczne.

Krótki przykład routingu w ASM dla wdrożenia canary opartego na nagłówku

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
  http:
  - match:
    - headers:
        user-agent:
          regex: ".*Android.*"
    route:
    - destination: { host: svc, subset: v2 }  # canary
  - route:
    - destination: { host: svc, subset: v1 }  # stable

Niezawodność testów, pętle informacji zwrotnej i dyscyplina po wydaniu

Zarządzanie niestabilnymi testami i niezawodność

Wykrywaj i poddawaj kwarantannie: Śledź niestabilność testów w czasie; izoluj znane niestabilne testy i nie blokuj nimi wydań, jednocześnie priorytetyzując ich naprawę.
Timeouty i ponowienia: Dodaj rozsądne timeouty; zezwalaj na jedno ponowienie w przypadku podejrzeń o błędy infrastruktury, a nie błędów logiki.
Hermetyczne buildy: Unikaj wywołań sieciowych w testach jednostkowych; przypinaj wersje artefaktów i używaj emulatorów, aby zredukować niedeterminizm.
Równoległość: Podziel testy w Cloud Build na wiele kroków lub workerów, aby zminimalizować opóźnienie w uzyskaniu informacji zwrotnej.

Pętle informacji zwrotnej

Wyzwalacze CI: Uruchamiaj testy jednostkowe i integracyjne przy każdym commicie do gałęzi main oraz przy pull requestach. Używaj oddzielnych kroków w Cloud Build, aby historia buildów wskazywała etap, który zawiódł. Twórz wyzwalacze wydań na tagach Git, a nie na każdym commicie, aby kontrolować wdrożenia.
Progresywna weryfikacja: Automatycznie promuj wdrożenie ze środowiska deweloperskiego (dev) na testowe (test) po udanym wdrożeniu, subskrybując powiadomienia Pub/Sub z Cloud Deploy i wywołując promocję przy zdarzeniach SUCCEEDED.
Promocja oparta na metrykach: W przypadku wdrożeń canary, uzależnij zwiększanie ruchu od metryk z Cloud Monitoring i wskaźników SLO.

Dokumentacja wydań, odpowiedzialność i weryfikacja po wdrożeniu

Dokumentacja: Utrzymuj notatki z wydania (release notes), runbooki i procedury wycofywania zmian (rollback) obok kodu. Śledź zgłoszenia zmian (change tickets) z linkami do commitów, obrazów i wersji środowisk.
Odpowiedzialność: Zdefiniuj rotacje dyżurów (on-call) i właścicieli komponentów; wymuszaj stosowanie pliku CODEOWNERS dla wrażliwych obszarów. Zapewnij jasno określone osoby zatwierdzające promocję na produkcję.
Weryfikacja po wdrożeniu: Uruchamiaj zestawy testów dymnych (smoke tests), upewnij się, że budżety błędów (error budgets) pozostają w normie i weryfikuj dashboardy według tagu wersji. Potwierdź, że raporty bezpieczeństwa i podatności pozostają zgodne z polityką. Jeśli pojawią się problemy, najpierw wycofaj zmiany, a następnie zbadaj przyczynę źródłową.

Praktyczny scenariusz problemu

Zespół platformowy w Acme Retail standaryzuje testowanie i wydania dla aplikacji opartej na mikroserwisach w GKE, która zawiera również bezstanowy frontend webowy w Cloud Run. Muszą zapewnić szybką informację zwrotną, blokować ryzykowne buildy i bezpiecznie wdrażać nowe funkcje, wykorzystując ruch produkcyjny do oceny wydajności.

Podejście

Oddzielenie etapów budowania i testowania w Cloud Build

Uzasadnienie: Użyj oddzielnych kroków do kompilacji, uruchamiania testów jednostkowych, budowania kontenera i uruchamiania testów integracyjnych, aby historia buildów precyzyjnie wskazywała etap, który zawiódł, a deweloperzy szybko otrzymywali użyteczne informacje zwrotne.
Przykład:

steps:
- name: gcr.io/cloud-builders/docker
  args: ['build', '-t', '$IMAGE', '.']
- name: gcr.io/cloud-builders/gcloud
  args: ['bash','-lc','make unit']
- name: gcr.io/cloud-builders/gcloud
  args: ['bash','-lc','make integration']  # against emulators
images: ['$IMAGE']

Uruchamianie testów integracyjnych na emulatorach i w efemerycznych przestrzeniach nazw

Uzasadnienie: Dla workerów Pub/Sub i usług korzystających z Firestore użyj emulatorów Pub/Sub i Firestore; dla usług wymagających polityk klastra, uruchamiaj efemeryczną przestrzeń nazw (namespace) GKE dla każdego builda z tymczasowymi tematami i kontami usługowymi za pośrednictwem Workload Identity. Zapewnia to izolację, szybkość i niski koszt przy jednoczesnym zachowaniu wierności odwzorowania.

Wymuszanie bramek jakości bezpieczeństwa za pomocą Artifact Registry i Binary Authorization

Uzasadnienie: Włącz skanowanie podatności przy wypychaniu obrazu (image push), zatrzymuj pipeline w przypadku krytycznych CVE i wymagaj atestacji w Binary Authorization przed wdrożeniem do GKE. Zapobiega to wdrażaniu obrazów ze znanymi krytycznymi podatnościami.

Używanie wyzwalaczy wydań opartych na tagach Git

Uzasadnienie: Wyzwalacze Cloud Build reagujące na tagi (np. vX.Y.Z) pozwalają na automatyczne wydania tylko dla jawnie oznaczonych commitów, co pozwala uniknąć przypadkowych wdrożeń produkcyjnych z każdego commita do gałęzi main.

Progresywne dostarczanie za pomocą Cloud Deploy i Anthos Service Mesh

Uzasadnienie: Zdefiniuj pipeline w Cloud Deploy z celami dev, test i prod. Użyj ręcznego zatwierdzenia jako bramki do promocji na produkcję. Dla produkcji zastosuj strategię canary z ASM, aby przenosić ruch w krokach 5%, 25%, 50%, 100%, monitorując jednocześnie wskaźniki SLO. Cloud Deploy subskrybuje hooki weryfikacyjne; niepowodzenie automatycznie zatrzymuje lub wycofuje wdrożenie canary za pośrednictwem API.

Obserwowalność i zautomatyzowane hooki do wycofywania zmian

Uzasadnienie: Eksportuj metryki Prometheus do Cloud Monitoring i twórz metryki oparte na logach dla sygnatur błędów. Skonfiguruj polityki alertów na metrykach oznaczonych wersją. Funkcja Cloud Function subskrybująca alerty wywołuje API Cloud Deploy, aby wstrzymać lub wycofać wdrożenie. Łączy to obiektywne sygnały o stanie systemu z kontrolą wdrożenia.

Ruch typu shadow i walidacja A/B dla frontendu w Cloud Run

Uzasadnienie: Użyj mirroringu żądań na zewnętrznym load balancerze HTTP(S), aby kierować żądania produkcyjne do nowej rewizji Cloud Run bez wpływu na użytkowników. Następnie użyj podziału ruchu (traffic-splitting) w Cloud Run, aby przenieść niewielkie procenty ruchu i porównać metryki opóźnień/błędów przed pełnym przełączeniem.

Mechanizm zapasowy blue-green dla krytycznych usług backendowych

Uzasadnienie: Dla usług wymagających natychmiastowego wycofania, utrzymuj wdrożenia blue i green za jedną usługą backendową. Zweryfikuj środowisko green za pomocą testów dymnych i kontraktowych, a następnie przełącz ruch. Wycofaj zmiany natychmiast, jeśli pojawią się anomalie.

Weryfikacja po wdrożeniu i dokumentacja

Uzasadnienie: Po promocji uruchom zautomatyzowane testy dymne, zweryfikuj dashboardy według wersji wydania i zaktualizuj notatki z wydania o skróty artefaktów (artifact digests) i historię wdrożenia. Właściciele i zespół dyżurujący (on-call) przejmują odpowiedzialność; jeśli budżety błędów (error budgets) zostaną wyczerpane, najpierw wycofaj zmiany, a następnie przeprowadź analizę post-mortem bez szukania winnych.

Takie podejście zapewnia szybką i niezawodną informację zwrotną w CI, wymusza bezpieczeństwo i jakość oraz wykorzystuje bezpieczne, obserwowalne strategie wdrażania, które wspierają zarówno eksperymenty oparte na atrybutach, jak i natychmiastowe wycofywanie zmian w razie potrzeby.

← Wydajność · Wszystkie domeny · Koszty →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →