Örnek sorular
Ci Cd PipelinesZorluk 1
Bir ekip, repository'ye yapılan her push'un otomatik olarak build tetiklediğini ve unit testleri çalıştırdığını söylüyor. Bu continuous integration'ı kapsar. Bu ekibin continuous delivery uyguladığını da söyleyebilmesi için ek olarak ne yapması gerekir?
- aHiçbir şey — her push'ta otomatik build ve test çalıştırmak zaten continuous delivery demektir.
- bGeliştiricilerin attığı her commit'te daha hızlı çalışsın diye test suite'ini baştan yazmak.
- cHer an deploy edilmeye hazır, doğrulanmış bir release artifact'i sürekli üretmek.✓
- dGeliştiricilerin feature branch'leri main'e sadece haftada bir manuel olarak merge etmesi.
Açıklama:Continuous integration, değişikliklerin otomatik build+test edilmesi demektir. Continuous delivery ise bir adım ötesidir: deploy kararı hâlâ bir insana ait olsa bile her an deploy'a hazır, doğrulanmış bir artifact bulundurmayı içerir. a şıkkı CI ile CD'yi karıştırır. b, delivery hazırlığıyla ilgisizdir. d ise seyrek manuel merge'i tarif eder ki bu, CI/CD'nin dayandığı sık entegrasyon hedefine ters düşer.
Ci Cd PipelinesZorluk 1
Tipik bir CI/CD pipeline'ı sıralı stage'lere ayrılır. Build, test ve deploy stage'lerinin genel amacını en doğru yansıtan sıralama hangisidir?
- aBuild kodu derler/paketler, test doğru davrandığını doğrular, deploy bir ortama yayınlar.✓
- bBuild kodu production'a yayınlar, test kullanıcı şikâyetlerini kontrol eder, deploy kaynağı derler.
- cBuild ve deploy aynı adımdır, test ise yalnızca ayda bir planlı denetimde çalışır.
- dTest her zaman build'den önce çalışır, çünkü eski test sonuçlarını önce okumak genel olarak hesaplama zamanı kazandırır.
Açıklama:Alışılagelmiş pipeline akışı build (derle/paketle) → test (doğruluğu doğrula) → deploy (bir ortama yayınla) şeklindedir; her stage bir sonrakinin kapısıdır. b şıkkı build ve deploy'un anlamını ters çevirir. c, build ile deploy'u yanlış birleştirir ve test'i her değişiklikten koparır. d ise doğal sırayı tersine çevirir; çünkü henüz build edilmemiş kod anlamlı biçimde test edilemez.
Ci Cd PipelinesZorluk 1
Pipeline terminolojisinde bir build "artifact"ını en iyi ne tanımlar?
- aBir pipeline stage'i bittikten sonra test runner'ın bastırdığı log çıktısı.
- bHangi branch'lerin bir pipeline çalıştırmasını tetikleyebileceğini listeleyen konfigürasyon dosyası.
- cBir geliştiricinin repository'ye değişiklik push ederken yazdığı commit mesajı.
- dBuild stage'inin ürettiği, paketlenmiş ve versiyonlanmış çıktı; binary, container image veya arşiv gibi.✓
Açıklama:Artifact, build stage'inin ürettiği somut ve versiyonlanmış çıktıdır — derlenmiş bir binary, paketlenmiş bir arşiv ya da container image — sonraki stage'ler bunu yeniden build etmeden deploy edebilir. a şıkkı log'u tarif eder, dağıtılabilir bir çıktı değildir. b, trigger konfigürasyonunu tarif eder. c, build çıktısıyla ilgisiz olan commit mesajını tarif eder.
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 1
"Pipeline as code", CI/CD pipeline tanımının (stage'ler, trigger'lar, job'lar) YAML gibi versiyonlanmış bir dosya olarak repository'de tutulması demektir. Ekiplerin bunu, pipeline'ı tamamen bir web arayüzünden yapılandırmaya tercih etmesinin temel pratik nedeni nedir?
- aYAML, arayüzde tutulan ayarlardan daha hızlı parse edildiği için pipeline'ı belirgin biçimde hızlandırır.
- bPipeline tanımının, diğer kod değişiklikleri gibi review edilmesini, versiyonlanmasını ve geri alınmasını sağlar.✓
- cBir deploy gerçekleşmeden önce pipeline'ın otomatik test çalıştırma zorunluluğunu ortadan kaldırır.
- dHer CI/CD aracı için zorunludur, çünkü artık hiçbiri arayüz üzerinden yapılandırma sunmamaktadır.
Açıklama:Pipeline'ı repository içinde bir dosya olarak tanımlamak, ona yapılan değişikliklerin uygulama koduyla aynı review, diff ve versiyon geçmişinden geçmesini sağlar ve pipeline'ı bozan bir değişiklik geri alınabilir. a şıkkı uydurma bir performans iddiasıdır, gerçek neden değildir. c ilgisiz ve yanlıştır — pipeline as code testi ortadan kaldırmaz. d abartılıdır; bazı araçlar hâlâ arayüz yapılandırması sunar, sadece izlenebilirlik açısından tercih edilmez.
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.