Senior CI/CD mülakat soruları ve cevapları: güvenli deployment tasarımı

CI/CD görüşmelerinde “GitHub Actions kullanıyorum” başlangıçtır. Senior cevap, değişikliğin testten production'a hangi güvenlik ve geri dönüş garantileriyle gittiğini açıklar.

1. CI ile CD'yi nasıl ayırırsınız?

CI her değişiklikte hızlı geri bildirim üretir: bağımlılık kurulumu, lint, typecheck, test, build ve gerekirse image taraması. CD ise onaylanmış artifact'ın belirli ortama güvenli biçimde taşınmasıdır. Aynı workflow içinde olabilirler ama yetki, secret ve tetikleyici ayrılmalıdır.

Önemli ilke: production'a kaynak kodu tekrar derleyerek değil, CI'ın ürettiği ve kimliği belli artifact/image ile deploy ederim. Böylece test edilen şey ile yayınlanan şey aynı olur.

2. Pipeline neden yavaşlar, nasıl iyileştirirsiniz?

Önce aşama sürelerini ölçerim. Lockfile'a bağlı dependency cache, Docker BuildKit cache, yalnızca etkilenen workspace'leri çalıştırma ve bağımsız kontrolleri paralelleştirme tipik kazanımlardır.

Monorepo'da Turborepo görev grafiği bunun için iyi bir temel sağlar. Dockerfile'da manifest'leri kaynak kodundan önce kopyalamak, bağımlılık katmanını cache'lenebilir tutar. Docker ve Turborepo rehberi bu katman düzenini detaylandırır.

3. Production deploy'unda neden concurrency gerekir?

Aynı ortama iki deploy aynı anda giderse migration, config veya container yeniden başlatma yarışabilir. CI sistemi için production gibi tek bir concurrency grubu tanımlarım. Eski bir commit'in deploy'u halen çalışırken yenisi geldiyse, ürün politikasına göre eskiyi iptal eder veya sıraya alırım.

Concurrency tek başına güvenlik değildir; environment protection, sadece izinli branch/tag'ler ve gerektiğinde insan onayıyla birlikte kullanılır.

4. Secret'ları nasıl yönetirsiniz?

Secret'ı repoya, Docker image'a veya build loglarına koymam. Ortama bağlı secret'ları deployment environment içinde tutar, yalnızca o environment'a yetkili job'a erişim veririm. Secret maskelemenin sızıntıyı tamamen önlemediğini kabul ederim: komut satırı argümanları, artifact'lar ve debug logları ayrıca denetlenmelidir.

5. Rollback planınız nedir?

Rollback deploy anında icat edilmez. Her release değişmez tag/digest ile tanımlanır; önceki image'a dönmek tek komut veya otomasyon olmalıdır. Şema değişiklikleri için backward-compatible, expand/contract migration yaklaşımı kullanırım: önce yeni alanı ekle, hem eski hem yeni sürümle çalış, kodu geçir, sonra eski alanı kaldır.

Başarılı pipeline, yeşil işaret değil; izlenebilir artifact, kontrollü yetki, çakışmayan deploy ve test edilmiş geri dönüş yoludur.