Her değişiklikte prod'a dağıtım yapmak korkutucu gelebilir, ama doğrudan prod'a dağıtım yapmamak daha korkutucudur.
Amazon'da yüz milyonlarca müşteriye dağıtım yapan bir ekibe liderlik ederken kullandığım süreç budur. Danışmanlık çalışmalarım sayesinde, mühendislik ekiplerini iki haftada bir planlı sürümlerle dağıtım yapmaktan, her merge'te canlıya çıkmaya geçirdim.
Bariz olanla başlayalım:
Bir kesintiye neden olacaksınız. Bu bir "eğer" meselesi değil, "ne zaman" meselesidir.
Ne kadar birim testi, entegrasyon testi, dogfooding, uçtan uca test ya da dağıtım tanrılarına kurban adarsanız adayın, her hatayı yakalayamazsınız.
Bir hafta önce özelliğiniz üzerinde yapılan testler, takım arkadaşınızın en son değişiklikleriyle test edilmedi.
Testleriniz, takım arkadaşınızın hizmetinin pre-prod sürümü üzerinde yapıldı; o sürüm ise artık değişti ve geriye dönük uyumsuz bir değişiklik içeriyor.
Ne kadar uzun beklerseniz, bir sürümde o kadar çok değişiklik birikir. Rollback yapmanız gerekirse, 1-2 saatlik değişiklikleri değil, iki haftalık değişiklikleri geri almanız gerekir.
Bir kesintinin kaçınılmaz olduğu öncülünü kabul edersek, bir sürümü QA'lamak için büyük kaynaklar harcamak çok daha az anlamlı hale gelir; bunun yerine kaynaklarımızı bir sürümü izlemeye ve gözlemlemeye ve bir kesinti olduğunda müdahale etmeye hazır olmaya odaklamalıyız.
Şimdi, oraya nasıl ulaşacağımıza geçelim:
Ön Koşullar:
CI/CD
Testler düşündüğünüzden çok daha az önemlidir. Testler, değişikliğinizin üretimde güvenli olduğunu kanıtlayamaz. Hiçbir şey kanıtlayamaz. Testlerin yaptığı şey, başarısızlığı ucuz hale getirmektir. CI'da yakalanan bir hata dakikalara mal olur. Üretimde yakalanan bir hata, akşamınızı rollback yaparak geçirmenize mal olur.
Bu yüzden her merge'te ya da en azından pipeline'ın bir parçası olarak tüm test paketini çalıştırın: birim, entegrasyon, uçtan uca testler. Hata pipeline'da ne kadar ilerlerse, çözmenin maliyeti o kadar artar.
İzleme / Gözlemlenebilirlik
Bu işin özü, bir regresyonu mümkün olan en kısa sürede yakalayabilmektir. Bunu başarmak için mükemmel bir izleme altyapınızın olması gerekir. Bu şu şekillerde karşımıza çıkar:
- metrikler: hatalar, gecikme, kullanılabilirlik
- korelasyon kimlikleri içeren loglar
- yukarıdaki ikisine bağlı sev-3 ve sev-2 (paging) alarmları
Alarm eşiklerinizi ayarlamak bir sanat ve bilim işidir. Hassasiyet ile gerçek bir olayda ne kadar hızlı tepki vereceğiniz arasında bir denge kurmanız gerekir. Hedef sev-2 uyarı süreniz 5-10 dakika olmalıdır.
Başlangıçta muhtemelen yanılacaksınız ve muhtemelen çok hassas olacaksınız. Ne yazık ki bu çoğunlukla deneme yanılma yoluyla öğreniliyor, bu yüzden başlangıçta birkaç kez gece 2'de uyanırsınız.
Özellik Bayrakları
Risk içeren herhangi bir değişikliği bir özellik bayrağı (feature flag) / uzak yapılandırma (remote config) arkasında yayınlamalısınız. Bir özellik bayrağı, tüm dağıtımı geri almak yerine herhangi bir değişikliği birkaç dakika içinde geri almanıza ve kapatmanıza olanak tanır. Ayrıca, özellik bayrağı hizmetiniz izin veriyorsa (ki vermelidir), özelliği kademeli olarak yüzdelik ya da kohort bazında kullanıma açabilir, böylece kötü bir değişikliğin etkisini daha da azaltabilirsiniz.
Bu, kodun dağıtımı ile kodun etkinleştirilmesini birbirinden ayırmamızı sağlar. İnce bir detay gibi görünür, ancak riski azaltmada oyunun kurallarını değiştiren bir şeydir.
Not: Bu bayrakları temizlemek için bir sürece ihtiyacınız olacak. İdeal olarak, oluşturulan her bayrak için bir kaldırma görevi (ticket) açmalısınız. Aksi takdirde, özellik bayrağı hizmetiniz çöktüğünde (çökecektir), ciddi bir regresyon yaşarsınız. Bunu nasıl bildiğimi sormayın.
Otomatik Geri Alma (Dağıtım Zamanı Devre Kesici)
Dağıtım zamanı devre kesici, dağıtımı sunucu filosu genelinde yayarken belirli bir sayıda veya oranda hata görürseniz dağıtımı geri almanıza olanak tanıyan bir işlevdir. Çoğu bulut sağlayıcısında bu artık basit bir onay kutusuyla mevcuttur.
Geriye Dönük Uyumlu Değişiklikler
Bunu zaten yapıyor olmalısınız, ancak her commit'te dağıtım yapmak bu pratiği zorunlu kılar. Kademeli dağıtım sırasında, eski sürüm ve yeni sürüm aynı anda çalışıyor olacak. Her değişikliğin önceki sürümle birlikte çalışması gerekir. Bunu önlemek için gece yarısı dağıtım yapma taktiğiniz artık işe yaramaz.
Dağıtım Stratejileri
Şimdi, bunlar yerindeyken, değişikliklerinizi yayınlarken riski azaltmaya yardımcı olabilecek birkaç farklı dağıtım stratejisini inceleyelim.
Tek Makine (Canary)
Tek makine dağıtımı, değişikliklerinizi daha büyük filodaki tek bir makineye dağıtır. Bu, kötü değişikliklerin etkisini yalnızca tek bir makineye indirmenizi sağlar.
Dağıtımı yaparsınız ve bu makinenin bir süre beklemesine izin verirsiniz; genel trafiğin küçük bir kısmını alır. İzleme ve uyarı sistemlerinizi bu makineye yapılandırmış olursunuz; bir şey bozulursa uyarı verir.
Kademeli Dağıtımlar
Kademeli dağıtım, zaman içinde yüzdelik bazda yayınlamanıza olanak tanır; böylece felaket niteliğinde bir hata olursa, tüm makineleri etkilemeden önce onu yakalayabilir ve ardından onları geri almaya başlayabilirsiniz.
Bölgesel Dağıtım
Şirketiniz büyüdükçe, çok bölgeli dağıtımlara sahip olacaksınız. Tüm bölgelere aynı anda dağıtım yapmak yerine, önce belirli bir bölgeye dağıtım yapabilirsiniz (genellikle en düşük trafiğe sahip bölgeye).
Bunun Geçerli Olmadığı Durumlar
Uygulama mağazası
Bir mobil uygulama yayınlamak bu rehberle tamamen uyumlu değildir. Uygulama mağazası inceleme kuyruğu, dağıtım ritminizi kısıtlar ve farklı bir strateji gerektirir.
Sertifikalı Ortamlar
Tıbbi cihazlar, havacılık elektroniği, endüstriyel kontrol vb. Yapıyı (build) bir düzenleyici kurumun sertifikalandırması gerekiyorsa sürekli dağıtım yapamazsınız.
On-prem / Self-hosted
Yükseltmeyi siz kontrol edemezsiniz. İşlettiğiniz her şeye sürekli dağıtım yapabilirsiniz, ancak yine de her değişikliğe bir sürüm numarası vermeniz gerekir ve müşteriniz, o değişikliğin ne zaman devreye alınacağına karar verir.
Nereden Başlamalı
Hepsini birden yapmayın. Sıralama önemlidir:
- CI'yı yeşil ve hızlı hale getirin. İdeal olarak 15 dakikanın altında.
- Hata oranı, gecikme ve kullanılabilirlik üzerinde metrikler ve alarmlar oluşturun. Bu, işin en önemli kısmı.
- Riskli herhangi bir değişikliği bir bayrak (flag) arkasına alın.
- Tek makine + otomatik geri alma ekleyin.
- Sürüm takvimini silin.
- Artık sürüm planlamadığınıza göre, kazandığınız tüm ekstra zaman için yeni bir kullanım alanı bulun.
Birlikte çalıştığım çoğu ekip bunu tamamlamak için yaklaşık bir çeyrek (üç ay) harcıyor. Araçlar kolay kısım. Organizasyon süreci ve planlı sürümlerin güvenli olduğu yanılsamasını yıkmak ise zor kısım.
Eğer takımınız bir sürüm takvimindeyse ve bundan çıkmak istiyorsa, yaptığım iş tam olarak bu. Bana DM atın.
