Örnek sorular
Deployment Release StrategiesZorluk 1
Yazılım teslimatı bağlamında bir 'deployment' en iyi şekilde nasıl tanımlanır?
- aBelirli bir uygulama sürümünün hedef bir ortamda çalışır ve erişilebilir hale getirilmesi süreci✓
- bKaynak kod değişikliklerini repository'ye yazıp commit'leme süreci
- cGeliştirme başlamadan önce veritabanı şemasının tasarlanması süreci
- dYeni bir özellik hiç yayınlanmadan önce onu tüm boyutlarıyla kapsamlı şekilde kapsayan otomatik test yazma ve bakımını yapma süreci
Açıklama:Deployment, build edilmiş bir artifact'ın bir ortamda (staging, production vb.) çalışır hale getirilmesidir. Kod commit'leme (b) source control faaliyetidir, deployment değildir. Test yazmak (d) geliştirme sürecinin parçasıdır ama başlı başına bir deployment adımı değildir.
Deployment Release StrategiesZorluk 1
Temel bir rolling update deployment stratejisinde ne olur?
- aTüm instance'lar yeni sürümle aynı anda değiştirilir
- bYeni sürümü çalıştıran instance'lar, eskilerinin yerini kademeli olarak, birkaçı birden alacak şekilde alır✓
- cYeni sürüm ayrı bir ortama deploy edilir ve trafik tek seferde değiştirilir
- dGerçek kullanıcı trafiğinin küçük bir yüzdesi test etmek için yeni sürüme yönlendirilir
Açıklama:Rolling update, instance'ları kademeli olarak değiştirir; bu sırada eski ve yeni sürüm bir süre birlikte trafik karşılar. (a) recreate/big-bang deployment'ı, (c) blue-green'i, (d) ise canary'i tanımlar.
Deployment Release StrategiesZorluk 1
Bir blue-green deployment'ta temel fikir nedir?
- aYeni sürüm kademeli olarak daha fazla trafik alırken eski sürüm geri kalanına hizmet vermeye devam eder
- bÖnce eski instance'lar kapatılır, ardından yeni instance'lar başlatılır
- cİki özdeş production ortamı bulunur; ortam hazır olduğunda trafik eski (blue) ortamdan yeni (green) ortama geçirilir✓
- dFeature toggle'lar, herhangi bir ortam geçişinden bağımsız olarak hangi kullanıcıların yeni kod yollarını göreceğini kontrol eder
Açıklama:Blue-green, iki tam ortamı canlı tutar ve tek seferlik bir cutover geçişi yapar. (a) canary'i, (b) recreate'i, (d) ise ortam geçişiyle ilgisi olmayan feature flagging'i tanımlar.
Deployment Release StrategiesZorluk 2
Bir ekip release riskini azaltmak için web servisinde blue-green deployment kullanmaya başlıyor. Bu ekibin beklemesi gereken gerçekçi bir trade-off nedir?
- aGo-live öncesinde yeni sürümün otomatik testini imkansız hale getirir
- bRolling update'e kıyasla toplam deployment süresini her zaman artırır
- cRollback planına duyulan ihtiyacı tamamen ortadan kaldırır
- dCutover penceresi sırasında genellikle iki katı altyapı kapasitesi çalıştırmayı gerektirir✓
Açıklama:Blue-green, en azından geçici olarak iki tam ortamın aynı anda çalışmasını gerektirir, bu da kaynak maliyetini ikiye katlar. (a) yanlış çünkü boşta olan ortam cutover öncesinde test edilebilir. (b) her zaman doğru değildir; geçişin kendisi hızlı olabilir. (c) rollback (geri geçiş) hâlâ gereklidir ve faydalıdır.
Deployment Release StrategiesZorluk 1
Bir canary deployment'ı ne tanımlar?
- aTam rollout öncesinde kullanıcıların veya trafiğin küçük bir alt kümesi önce yeni sürüme yönlendirilir✓
- bYeni ve eski sürüm tamamen ayrı ortamlarda çalışır ve tek seferlik trafik geçişi yapılır
- cTüm sunucular aynı anda yeni sürüme güncellenir
- dYeni sunucular hazırlanmadan önce eski sunucular sonlandırılır
Açıklama:Canary, sorunların erken yakalanabilmesi için yeni sürümü önce sınırlı bir trafik dilimine açar. (b) blue-green'i, (c) ve (d) ise recreate/big-bang deployment'ın varyantlarını tanımlar.
Deployment Release StrategiesZorluk 2
Bir ekip, yüksek trafikli bir servis için regresyonları erken yakalamak amacıyla canary deployment kullanmak istiyor. Canary'nin etkili olması için ekibin en çok hangi operasyonel yeteneğe ihtiyacı vardır?
- aİlkini her konfigürasyon detayında birebir yansıtan, tamamen izole ikinci bir production ortamı
- bHer sürüm için kritik metrikleri izleme ve canary ile baseline davranışını karşılaştırma yeteneği✓
- cYalnızca backend geliştiricilerin erişebildiği bir feature flag sistemi
- dCanary'yi her zaman tam olarak bir saat sonra promote eden sabit bir zamanlama
Açıklama:Sürüm bazlı izleme ve karşılaştırma olmadan ekip canary'nin gerçekten güvenli davranıp davranmadığını anlayamaz. (a) bir blue-green ihtiyacını tanımlar, canary gereksinimi değildir. (c) ilgisiz bir kısıtlamadır. (d) gerçek sinyalleri göz ardı edip sabit bir zamanlayıcıya güvenmek yaygın bir junior hatasıdır.