Google PCD: Test, Kalite Mühendisliği ve Güvenli Sürüm Yönetimi — Çalışma kılavuzu

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

Şunun bir parçası: Google Professional Cloud Developer — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Google sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Genel Bakış

Google Cloud’da yüksek hızda çalışan ekipler, değişimi hızlandırırken riski azaltmak için sıkı testleri aşamalı teslimatla birleştirir. Sağlam bir strateji, birim testlerinden uçtan uca testlere, gerçekçi veri ve bağımlılık simülasyonuna, otomatik kalite kapılarına ve kanarya (canary) ve mavi-yeşil (blue-green) gibi kontrollü sürüm desenlerine kadar uzanır. Gözlemlenebilirlik, sahiplenme ve disiplinli sürüm sonrası doğrulama döngüyü tamamlar. Bu bölümde, Google Cloud hizmetleriyle güvenilirlik için nasıl tasarım yapılacağı, riskin nasıl izole edileceği ve derlemelerin (build) ortamlar arasında nasıl güvenli bir şekilde yükseltileceği ayrıntılı olarak anlatılmaktadır.

Test Stratejisi ve Veri Yönetimi

Test piramidi ve test türleri

Birim testleri: Fonksiyonların, sınıfların ve küçük modüllerin hızlı, yalıtılmış doğrulaması. Test paketinin büyük çoğunluğunu bunlar oluşturmalıdır. Her commit ve pull request’te çalıştırın.
Entegrasyon testleri: Uygulama ve veritabanı veya kuyruk gibi bileşenler arasındaki etkileşimleri doğrulayın. Mümkün olan yerlerde Google Cloud emülatörlerini kullanın.
Sözleşme testleri (Contract tests): Mikroservisler için tüketici odaklı sözleşmeler (consumer-driven contracts), API’da yıkıcı değişiklikleri (breaking changes) önler. Sağlayıcı (provider) davranışını, entegrasyondan önce tüketicinin beklediği şema ve semantiğe göre doğrulayın. Pact veya benzeri araçları kullanın; API’nizi sürümleyin ve şemaları yayınlayın.
Uçtan uca testler: Üretim benzeri yapılandırma, kimlik ve ağ politikaları kullanarak tüm sistem yolunu çalıştırın. Sayılarını sınırlayın, paralelleştirin ve üretim öncesi (pre-prod) ortamlarda çalıştırın.
Duman testleri (Smoke tests): Her dağıtımdan sonra kritik bağımlılıkların, rotaların ve sağlık kontrollerinin (health checks) doğru davrandığını onaylayan minimal sondajlar. Bunlar dağıtım sonrası ilk doğrulamalarınızdır.

Test verisi yönetimi, yalıtım, tekrarlanabilirlik ve ortam denkliği

Veri hazırlama (Data seeding): Birim testleri için küçük, deterministik veri setleri ve entegrasyon/performans testleri için daha büyük, temsili veri setleri oluşturun. Kaynak kontrolüne eklenmiş fikstürlerden (fixtures) veri hazırlayın.
Yalıtım: Testlerin durum (state) paylaşmadığından emin olun. Geçici (ephemeral) veritabanları, yalıtılmış GKE ad alanları (namespaces) ve Cloud Storage nesneleri için benzersiz önekler kullanın. SQL için test başına şemalar oluşturun; Pub/Sub için geçici topic’ler/subscription’lar oluşturun.
Tekrarlanabilirlik: Bağımlılık sürümlerini sabitleyin, derlemeleri hermetik yapın ve rastgele tohumları (random seeds) sabitleyin. Test konteynerlerini özetleriyle (digests) birlikte Artifact Registry’de saklayın.
Ortam denkliği: Geliştirme (dev), QA, hazırlık (staging) ve üretim (production) ortamlarında konteyner imajlarını ve kod olarak altyapıyı (infrastructure-as-code) standartlaştırın. Yapılandırmayı imajların dışında tutun ve ortama özgü meta verileri ve gizli bilgileri (secrets) kullanın. Compute Engine için, dağıtım başına değerleri örnek şablonu (instance template) meta verilerinde saklayın; projeler arası denklik için bir ortam meta veri anahtarı yapılandırın ve başlangıçta bunu okuyarak ortama özgü yapılandırmayı seçin.

Mock’lama, emülatörler, sahteler (fakes) ve sanal alan (sandbox) hizmetleri

Mock’lar/stub’lar: Mantığı izole etmek ve ağ çağrılarını kesmek için birim seviyesinde işbirlikçileri (collaborators) değiştirin. Aşırı mock’lamadan kaçının; uygulama detaylarına değil, davranışa göre iddiada bulunun (assert).
Emülatörler: Entegrasyon testleri için resmi emülatörleri tercih edin. Örnekler: Firestore/Datastore, Pub/Sub, Spanner ve Bigtable emülatörleri. Bunlar, bulut ücretleri olmadan API doğruluğu sağlar ve CI’ı hızlandırır.
Sahteler (Fakes): Emülatör olmadığında, hafif yerel sahteler (örneğin, sahte bir nesne deposu) veya güçlü yalıtım ve kotalara sahip paylaşılan sanal alan hizmetleri çalıştırın.
Harici bağımlılık simülasyonu: Üçüncü taraf API’ler için, bir hizmet ağı (service mesh) veya API ağ geçidinin (API gateway) arkasında sözleşme tabanlı sahteler çalıştırın; hata işlemeyi test etmek için zaman aşımlarını (timeouts), yeniden denemeleri (retries) ve kaos enjeksiyonunu (chaos injection) yapılandırın.

Yaygın hata modları ve ödünleşimler

Uçtan uca testlere aşırı güvenmek yinelemeyi yavaşlatır; sorunları daha erken yakalamak için birim ve sözleşme testlerine yatırım yapın.
Paylaşılan, uzun ömürlü test ortamları sapma (drift) ve veri kirliliği biriktirir. Geçici ortamları ve bir kez etkili (idempotent) kurulum/kaldırma işlemlerini tercih edin.
Emülatörler üretimi mükemmel bir şekilde yansıtmayabilir. Yükseltmeden önce gerçek hizmetlerle aşamalı E2E testleri kullanın.

Başarısız olan aşamaları ayırmak için kısa bir Cloud Build örneği

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']

Ayrı adımlar, derleme geçmişinin derleme/birim, inşa (build) veya entegrasyon aşamalarından hangisinin başarısız olduğunu tam olarak belirlemesini sağlar.

Fonksiyonel Olmayan Testler ve Kod Kalitesi

Performans testi

Türler: Yük (sabit durum), stres (zirvenin ötesi), ıslatma (uzun süreli) ve kapasite testleri.
Araçlar: SLO’lar ve uyarılar için Cloud Monitoring, gecikme dökümü için Cloud Trace ve sıcak yolları (hot paths) belirlemek için Cloud Profiler kullanın. GKE için Cluster Autoscaler ve HPA ile ölçeklendirin; Pub/Sub çalışanları için harici metrikler üzerindeki HPA, ani artış odaklı ölçeklendirmeyi yönetir.
Üretim testi: Yeni arka uçları (backends) üretim trafiğiyle güvenli bir şekilde değerlendirmek için karanlık lansmanlar (dark launches) ve istek yansıtma (request mirroring) kullanın. External HTTP(S) Load Balancing, istek yansıtmayı destekler; Anthos Service Mesh, trafik gölgelemeyi (traffic shadowing) destekler.

Güvenlik testi

SAST/gizli bilgi taraması: CI’da statik analizörler çalıştırın ve koda gömülü kimlik bilgilerini reddedin. Gizli bilgileri en az ayrıcalık (least-privilege) erişimiyle Secret Manager’da saklayın.
Bağımlılık ve imaj taraması: Artifact Registry üzerinde Container Analysis’i etkinleştirin. Dağıtımdan önce kritik güvenlik açığı bulunmadığına dair onayları (attestations) gerektiren Binary Authorization ile politikayı zorunlu kılın.
DAST: Hazırlık (staging) ortamlarını kimliği doğrulanmış tarayıcılarla tarayın ve kritik bulgularda sürümleri engelleyin.

Erişilebilirlik ve regresyon

Erişilebilirlik: Otomatikleştirilmiş a11y kontrollerini (örneğin, Lighthouse CI) engellemeyen birleştirme öncesi kontrollere (pre-merge checks) entegre edin; sürümden önce düzeltin.
Regresyon paketleri: Kritik yolculuklar için özel olarak hazırlanmış, kararlı regresyon paketleri bulundurun. Her dağıtımda duman testlerini ve sürüm adaylarında tam regresyonu çalıştırın.

Statik analiz, kalite kapıları ve kod incelemesi

Statik analiz: Dile uygun linter’ları ve formatlayıcıları gönderim öncesi kontroller (pre-submit checks) olarak yapılandırın. Paralelleştirmek için Bazel veya benzerini kullanın.
Kalite kapıları: Eşik aşımlarında (kapsam, karmaşıklık, lint hataları) derlemeleri başarısız kılın. Sonuçları Cloud Build günlüklerine yayınlayın.
Kod incelemesi: Riskli değişiklikler için iki kişilik inceleme, kritik yollar için CODEOWNERS ve sürümler için kullanılan etiketlerde (tags) gönderim öncesi CI (presubmit CI) gerektirin.
Tedarik zinciri: SBOM’lar oluşturun, yapıtları (artifacts) imzalayın ve köken bilgilerini (provenance) saklayın. Binary Authorization’da onay (attestation) kontrollerini zorunlu kılın.

Aşamalı Teslimat ve Güvenli Sürümler

Dağıtım stratejileri

Rolling (Kademeli): Pod’ları veya instance’ları artımlı olarak değiştirin. Durumsuz (stateless) servisler için düşük risklidir; hazırlık denetimleri (readiness probes) ve artış/kullanılabilirlik ayarlarıyla birleştirin.
Blue-green (Mavi-yeşil): Tamamen yeni bir ortam kurun, doğrulamayı çalıştırın, ardından trafiği değiştirin. Yük dengeleyiciyi (load balancer) geri çevirerek anında geri alma sağlar. Anında geri dönüşe ihtiyaç duyduğunuzda idealdir.
Canary (Kanarya): Temel metrikleri izlerken trafiğin küçük bir yüzdesini kademeli olarak yeni sürüme kaydırın. Sağlıklıysa yükseltmeyi otomatikleştirin; regresyonlarda geri alın.
Trafik bölme: GKE ve Anthos Service Mesh ile yüzdeye veya niteliklere (başlıklar, çerezler, kullanıcı aracısı) göre yönlendirin ya da Cloud Run ve App Engine’deki yerleşik bölme özelliğini kullanın.

Özellik bayrakları ve deneme

Özellik bayrakları: Dağıtımı sürümden ayırın. Kademeli sunum, kapatma anahtarları (kill switch) ve deneme anahtarları için bayrakları kullanın. Merkezi olarak saklayın (örneğin, yönetilen bir bayrak hizmeti veya IAM ile korunan bir yapılandırma deposu). Bayrak ömürlerini kısa tutun ve gereksizleri temizleyin.
Dark launches (Karanlık lansmanlar): Özellikleri devre dışı bırakılmış olarak dağıtın; dahili kullanıcılar veya sentetik trafik aracılığıyla doğrulayın.
Shadow traffic (Gölge trafik): Kullanıcıları etkilemeden üretim isteklerini yeni servislere yansıtın; regresyonları tespit etmek için yanıtları karşılaştırın.
Kontrollü deneyler: Servis mesh kurallarıyla A/B veya çok değişkenli yönlendirme uygulayın. Kullanıcı aracısı (user-agent) tabanlı deneyler için başlık (header) eşleşmesine göre yönlendirme yapın.

Kapılar, onaylar, geri alma ve gözlemlenebilirlik

Dağıtım kapıları: Dağıtım öncesi entegrasyon testleri ve dağıtım sonrası duman/sağlık kontrolleri (smoke/health checks) ekleyin. Ortam yükseltmeleri için, derlemeyi (build) sürümden (release) ayırmak üzere etiket tabanlı tetikleyiciler kullanın.
Manuel onaylar: Hazırlık (staging) ortamından üretim (production) ortamına geçiş gibi kilometre taşlarında insan onayı gerektirin. Cloud Deploy, her hedef için manuel onay adımlarını destekler.
Otomatik geri alma: SLO’ları ve uyarı politikalarını tanımlayın; bir kanarya sürümü hata oranı veya gecikme eşiklerini ihlal ettiğinde, dağıtım API’sini çağırarak otomatik olarak geri alın. Geri alma işlemlerini hızlı ve iyi prova edilmiş tutun.
Sürüm gözlemlenebilirliği: Sürümleri, metriklerde ve loglarda sürüm etiketleriyle enstrümante edin. Prometheus metriklerini Cloud Monitoring’e aktarın ve telemetriyi uygun maliyetli bir şekilde ilişkilendirmek için hata desenleri için log tabanlı metrikler oluşturun.

Başlık tabanlı kanarya için kısa bir ASM yönlendirme örneği

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

Test Güvenilirliği, Geri Bildirim Döngüleri ve Sürüm Sonrası Disiplin

Kararsız test (flaky-test) yönetimi ve güvenilirlik

Tespit et ve karantinaya al: Testlerin kararsızlığını zaman içinde takip edin; bilinen kararsız testleri karantinaya alın ve düzeltmelere öncelik verirken sürümlerin bu testler yüzünden engellenmesine izin vermeyin.
Zaman aşımları ve yeniden denemeler: Mantıklı zaman aşımları ekleyin; mantık hataları için değil, şüphelenilen altyapı kaynaklı kararsızlıklarda tek bir yeniden denemeye izin verin.
Hermetik derlemeler: Birim testlerinde ağ çağrılarından kaçının; belirsizliği azaltmak için artifact’leri sabitleyin ve emülatörler kullanın.
Paralelleştirme: Geri bildirim gecikmesini en aza indirmek için Cloud Build’de testleri birden çok adıma veya çalışana (worker) paylaştırın (shard).

Geri bildirim döngüleri

CI tetikleyicileri: Main dalına yapılan her commit ve pull request’lerde birim ve entegrasyon testlerini çalıştırın. Derleme geçmişinin hatalı aşamayı belirlemesi için ayrı Cloud Build adımları kullanın. Dağıtımları kontrol etmek için her commit’te değil, Git etiketlerinde sürüm tetikleyicileri oluşturun.
Aşamalı doğrulama: Cloud Deploy Pub/Sub bildirimlerine abone olarak ve SUCCEEDED olaylarında yükseltmeyi (promotion) çağırarak, başarılı dağıtımın ardından dev ortamından test ortamına otomatik olarak yükseltin.
Metrik odaklı yükseltme: Canary dağıtımları için, trafiğin artırılmasını Cloud Monitoring metriklerine ve SLO’lara dayalı olarak kontrol edin (gate).

Sürüm dokümantasyonu, sahiplik ve sürüm sonrası doğrulama

Dokümantasyon: Sürüm notlarını, runbook’ları ve geri alma (rollback) prosedürlerini kodun yanında tutun. Değişiklik biletlerini (ticket) commit’lere, imajlara ve ortam sürümlerine bağlantılarla takip edin.
Sahiplik: Nöbetçi (on-call) rotasyonlarını ve bileşen sahiplerini tanımlayın; hassas alanlar için CODEOWNERS dosyasını zorunlu kılın. Üretim ortamına yükseltmeler için onaylayıcıların net olduğundan emin olun.
Sürüm sonrası doğrulama: Smoke testlerini çalıştırın, hata bütçelerinin (error budget) sağlıklı kaldığından emin olun ve panoları (dashboard) sürüm etiketine göre doğrulayın. Güvenlik ve zafiyet raporlarının politika dahilinde kaldığını teyit edin. Sorun çıkarsa, önce geri alın (roll back), sonra kök neden analizi yapın.

Pratik Problem Senaryosu

Acme Retail’in platform ekibi, GKE tabanlı bir mikroservis uygulaması için test ve sürüm süreçlerini standartlaştırıyor. Bu uygulama aynı zamanda Cloud Run üzerinde durumsuz (stateless) bir web arayüzü de içeriyor. Ekibin, performansı değerlendirmek için canlı trafiği kullanırken hızlı geri bildirim sağlaması, riskli derlemeleri engellemesi ve yeni özellikleri güvenli bir şekilde kullanıma sunması gerekiyor.

Yaklaşım

Cloud Build’de derleme ve test aşamalarını ayırma

Gerekçe: Derleme, birim testlerini çalıştırma, container oluşturma ve entegrasyon testlerini çalıştırma için ayrı adımlar kullanın. Böylece derleme geçmişi hatalı aşamayı tam olarak belirler ve geliştiriciler hızlıca eyleme geçirilebilir geri bildirim alır.
Örnek:

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']

Entegrasyon testlerini emülatörlere ve geçici (ephemeral) namespace’lere karşı çalıştırma

Gerekçe: Pub/Sub worker’ları ve Firestore destekli servisler için Pub/Sub ve Firestore emülatörlerini kullanın; küme politikaları gerektiren servisler için, her derleme başına Workload Identity aracılığıyla geçici topic’ler ve hizmet hesapları (service account) ile geçici bir GKE namespace’i oluşturun. Bu, aslına uygunluğu korurken izolasyon, hız ve düşük maliyet sağlar.

Artifact Registry ve Binary Authorization ile güvenlik kalite kapılarını (quality gate) zorunlu kılma

Gerekçe: İmaj push edildiğinde zafiyet taramasını etkinleştirin, kritik CVE’lerde pipeline’ı başarısız kılın ve GKE’ye dağıtım yapmadan önce Binary Authorization’da onayları (attestation) zorunlu tutun. Bu, bilinen kritik zafiyetlere sahip imajların dağıtılmasını önler.

Git etiket tabanlı sürüm tetikleyicileri kullanma

Gerekçe: Etiketler (örneğin, vX.Y.Z) üzerindeki Cloud Build tetikleyicileri, yalnızca açıkça etiketlenmiş commit’ler için otomatik sürümlere izin verir ve main dalına yapılan her commit’ten yanlışlıkla üretim dağıtımları yapılmasını önler.

Cloud Deploy ve Anthos Service Mesh ile aşamalı teslimat (progressive delivery)

Gerekçe: Dev, test ve prod hedefleri olan bir Cloud Deploy pipeline’ı tanımlayın. Prod ortamına yükseltmeyi kontrol etmek için manuel onay kullanın. Prod için, SLO’ları izlerken trafiği %5, %25, %50, %100 oranında kaydırmak için ASM ile bir canary stratejisi kullanın. Cloud Deploy, doğrulama hook’larına abone olur; bir hata durumunda API aracılığıyla canary dağıtımını otomatik olarak durdurur veya geri alır.

Gözlemlenebilirlik ve otomatik geri alma (rollback) hook’ları

Gerekçe: Prometheus metriklerini Cloud Monitoring’e aktarın ve hata imzaları için log tabanlı metrikler oluşturun. Sürüm etiketli metrikler üzerinde uyarı politikaları yapılandırın. Uyarılara abone olan bir Cloud Function, dağıtımı duraklatmak veya geri almak için Cloud Deploy API’sini çağırır. Bu, nesnel sağlık sinyallerini dağıtım kontrolüne bağlar.

Cloud Run arayüzü için gölge trafik (shadow traffic) ve A/B doğrulaması

Gerekçe: Kullanıcıları etkilemeden üretim isteklerini yeni Cloud Run revizyonuna beslemek için harici HTTP(S) load balancer’da istek yansıtmayı (request mirroring) kullanın. Ardından, tam geçişten önce küçük yüzdeleri kaydırmak ve gecikme/hata metriklerini karşılaştırmak için Cloud Run’ın trafik bölme (traffic-splitting) özelliğini kullanın.

Kritik arka uç (backend) servisleri için blue-green geri dönüş (fallback) planı

Gerekçe: Anında geri alma gerektiren servisler için, tek bir backend service arkasında blue ve green dağıtımlarını sürdürün. Green dağıtımını smoke ve contract testleri ile doğrulayın, ardından trafiği değiştirin. Anormallikler ortaya çıkarsa anında geri dönün.

Sürüm sonrası doğrulama ve dokümantasyon

Gerekçe: Yükseltmeden sonra, otomatik smoke testlerini çalıştırın, panoları sürüm versiyonuna göre doğrulayın ve sürüm notlarını artifact özetleri (digest) ve dağıtım geçmişi ile güncelleyin. Sahiplik ve nöbetçi (on-call) ekip devralır; hata bütçeleri (error budget) tükenirse, önce geri alın, ardından suçlayıcı olmayan bir analiz yapın.

Bu yaklaşım, CI sürecinde hızlı ve güvenilir geri bildirim sağlar, güvenlik ve kaliteyi zorunlu kılar ve hem nitelik tabanlı deneyleri hem de gerektiğinde anında geri almayı destekleyen güvenli, gözlemlenebilir dağıtım stratejileri kullanır.

← Performans · Tüm alanlar · Maliyet →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →