Örnek sorular
Ci Cd PipelinesZorluk 2
Bir pipeline config parçası şu dependency kurulum adımını içeriyor:
- name: Install dependencies
run: npm ci
cache:
path: ~/.npm
key: npm-${{ hashFiles('package-lock.json') }}
Buradaki
cache bloğunun sağladığı temel pratik fayda nedir?
- aPipeline'ın her çalışmada mutlaka en güncel dependency sürümlerini deploy etmesini garanti eder.
- bLockfile değişmediğinde daha önce indirilmiş paketleri yeniden kullanarak sonraki çalışmaları hızlandırır.✓
- cCache key için bir kayıt varsa
npm ci komutunu tamamen çalıştırmaya gerek bırakmaz. - dBuild edilmiş uygulama artifact'ini kalıcı olarak saklar, böylece deploy stage build'i atlar.
Açıklama:Lockfile hash'ine göre anahtarlanan dependency cache, dependency'ler değişmediğinde paketlerin yeniden indirilmesi yerine önceden indirilmişleri geri yükler ve kurulum süresini kısaltır. a şıkkı cache'in yaptığının tersidir (cache yeniden kullanımı önceler, her zaman en güncelini çekmeyi değil). c yanlıştır — cache hit olsa bile npm ci yine çalışır ve lockfile'a karşı doğrulama yapar. d, dependency cache'i ayrı bir kavram olan build artifact'i ile karıştırır.
Ci Cd PipelinesZorluk 2
Bir ekip, pipeline'ının her pull request'te tüm test suite'ini çalıştırmasını, her gece zamanlanmış olarak daha hafif bir smoke test çalıştırmasını ve yalnızca biri doğrudan main branch'e push ettiğinde bir base dependency image'ını yeniden build etmesini istiyor. Farklı olayları bu şekilde farklı işlere yönlendirmeyi sağlayan pipeline kavramı hangisidir?
- aEnvironment promotion; testler başarıyla geçtikten sonra deploy edilen artifact'in hangi ortama gideceğini kontrol eder.
- bBuild caching; ayrı pipeline çalışmaları arasında önceden indirilmiş dependency'leri geri yükler.
- cTrigger'lar; bir pull request, bir schedule veya bir push gibi hangi olayların hangi job'u başlattığını tanımlar.✓
- dArtifact retention; build çıktılarının silinmeden önce ne kadar süre depoda tutulacağına karar verir.
Açıklama:Trigger'lar, pipeline job'larını belirli olaylara (PR açılması, cron schedule, bir branch'e push) bağlayan mekanizmadır ve farklı durumlar için farklı job'ların çalışmasını sağlar. a, doğrulandıktan sonra artifact'in nereye gittiğiyle ilgilidir, bir job'u neyin başlattığıyla değil. b, dependency kurulumunu hızlandırmayla ilgilidir, olay yönlendirmeyle ilgisizdir. d, artifact yaşam döngüsü/temizliğiyle ilgilidir, bir job'un çalışmasına neyin sebep olduğuyla değil.
Ci Cd PipelinesZorluk 2
Bir ekip trunk-based development kullanıyor: herkes küçük değişiklikleri günde birkaç kez main'e merge edilen kısa ömürlü bir branch üzerinden commit'liyor ve pipeline her merge'de çalışıyor. Yeni işe başlayan biri bunun yerine haftalarca açık kalan uzun ömürlü feature branch'ler kullanılmasını ve pipeline'ın yalnızca final merge'den hemen önce çalıştırılmasını öneriyor. Bu önerinin pipeline ile ilgili temel dezavantajı nedir?
- aEntegrasyon sorunları ve test hataları birikir ve ancak izole etmesi zorlaştığında, geç ortaya çıkar.✓
- bPipeline'ın farklı bir araçla yeniden yazılması gerekir, çünkü uzun ömürlü branch'ler desteklenmez.
- cBuild artifact'leri artık versiyonlanamaz, çünkü bir branch adı hiçbir şekilde bir version tag'ine dahil edilemez.
- dTest stage'leri tamamen kaldırılmalıdır, çünkü yalnızca kısa ömürlü branch'lerde doğru çalışırlar.
Açıklama:Branch stratejisi ile pipeline tasarımı birbirine bağlıdır: continuous integration'ın değeri, değişikliklerin sık ve küçük parçalar halinde test edilmesinden gelir. Uzun ömürlü branch'ler bu geri bildirimi geciktirir, bu yüzden uyumsuzluklar ve başarısız testler birikir ve nihayet merge edildiğinde tek bir değişikliğe bağlamak zorlaşır. b, c ve d şıklarının hepsi yanlış teknik iddialardır — pipeline'lar, versiyonlama ve test stage'leri branch ömründen bağımsız çalışır; gerçek maliyet araç bozulması değil, gecikmiş geri bildirimdir.
Ci Cd PipelinesZorluk 2
Bir pipeline job'unun bir cloud sağlayıcısına deploy yapabilmesi için bir API key'e ihtiyacı var. CI/CD pipeline'ında bu tür bir secret'ı yönetmek için yaygın pratiğe en uygun yaklaşım hangisidir?
- aAPI key'i doğrudan pipeline YAML dosyasına hardcode etmek, böylece her takım arkadaşı görüp yeniden kullanabilir.
- bAPI key'i pull request'e yorum olarak yapıştırmak, böylece reviewer'lar doğru olduğunu teyit edebilir.
- cHataları debug etmek daha kolay olsun diye job başında API key'i pipeline log'larına yazdırmak.
- dAPI key'i pipeline'ın yerleşik secret store'unda saklamak ve maskelenmiş bir environment variable olarak referans vermek.✓
Açıklama:CI/CD araçları, hassas değerlerin at-rest şifrelenmesi, yalnızca çalışma zamanında enjekte edilmesi ve log'larda maskelenmesi için tam olarak bu amaçla özel bir secret store sunar — version control'da veya düz metinde açığa çıkmasını önler. a, bir credential'ı version-controlled ve geniş çapta okunabilir kaynak koduna koyar. b, onu bir PR yorumunda ifşa eder ki bu repository'nin kendisinden bile daha az kontrollüdür. c, bilerek yazdırarak maskelemeyi işlevsiz kılar ve log erişimi olan herkese ifşa riski yaratır.
Ci Cd PipelinesZorluk 2
Bir pipeline job config'i stage'lerini şöyle listeliyor:
pipeline:
stop-on-failure: true
steps:
- lint
- unit-test
- integration-test
- deploy
stop-on-failure: true ile
unit-test adımı başarısız olursa ne olur?
- aPipeline,
integration-test'e geçmeden önce unit-test'i otomatik olarak üç kere yeniden dener. - bPipeline hatayı görmezden gelir ve
integration-test ile deploy'u planlandığı gibi çalıştırmaya devam eder. - cPipeline hemen durur;
integration-test ve deploy atlanır, kalan adımlar çalıştırılmaz.✓ - dPipeline durur ve
integration-test'in çalışıp çalışmayacağının bir insan tarafından manuel onaylanmasını bekler.
Açıklama:stop-on-failure (fail-fast) politikası, bir adım başarısız olur olmaz pipeline'ın durması, muhtemelen ona bağımlı sonraki adımları çalıştırmaya devam etmemesi demektir; bu zaman kazandırır ve bozuk bir build'in deploy edilmesini önler. a, bazı araçların sunduğu ayrı ve ilgisiz bir özellik olan otomatik retry'ı uydurur, bu ayarın yaptığı şey değildir. b tam tersi davranışı tarif eder. d, bu ayarın ima etmediği bir manuel onay kapısı uydurur.
Ci Cd PipelinesZorluk 2
Junior bir mühendis, her merge'den sonra production'a deploy'lar daha hızlı olsun diye pipeline'dan otomatik test stage'inin kaldırılmasını öneriyor. Bu öneriye karşı çıkmak için en güçlü gerekçe nedir?
- aOtomatik testler yalnızca ilk geliştirme aşamasında faydalıdır, uygulama production'a ulaştıktan sonra değeri kalmaz.
- bTest stage'i olmadan pipeline, regresyonları canlı ortama ulaşmadan önce yakalayamaz.✓
- cPipeline config dosyasından bir stage kaldırmak genellikle pipeline aracının kendisinin çalışmayı durdurmasına neden olur.
- dTest stage'leri her CI/CD aracı tarafından zorunlu kılınır ve bir pipeline tanımından teknik olarak kaldırılamaz.
Açıklama:Test stage'i, kötü bir değişikliğin kullanıcılara ulaşmadan önce regresyonları yakalayan otomatik kapıdır — onu kaldırmak, daha hızlı bir pipeline karşılığında bozuk davranış gönderme riskinde gerçek bir artış anlamına gelir. a yanlış bir genellemedir; testler bir projenin tüm ömrü boyunca değerlidir. c uydurma bir araç arızası uydurur. d de yanlıştır — çoğu araç stage'lerin serbestçe kaldırılmasına izin verir, bu kötü bir pratiktir ama teknik olarak imkânsız değildir.