Staging’in sorunları
- pre-live, production ile aynı değil
- bir release kuyruğu oluşuyor
- release’ler fazla büyüyor
- değişiklikler üzerinde yeterli sahiplik yok
- sürecin sorumluluğun yerini almasına izin veriliyor
Squeaky nasıl ship ediyor
- yalnızca canlıya alınabilecek şeyler merge ediliyor: değişiklikler için yerel geliştirme ortamında yeterince test yapılıyor
- düz bir branching stratejisi kullanılıyor: feature merge edilmeye hazır olduğunda rebase edilip test ediliyor. Sorun çıkarsa roll forward yapılıyor
- yüksek riskli feature’larda her zaman feature flag kullanılıyor
- manuel deployment: değişiklikten sonra sürekli izleme yapılıyor. Monitoring/logging/alarm tüm genel yapıya uygulanmış durumda. Blue/green deployment
Sonuç
- gerçek CI/CD için staging ortamından vazgeçmek, yazılımı ship etme konusunda farklı bir düşünce biçimi oluşturabilir
- değişiklikler canlıya alınmadan önce bir tampon yoksa, bu değişikliklerin production için uygun olduğundan emin olmak gerekir
- yaptığınız her değişiklikte sahiplik almalı ve dikkatli olmalısınız
- altyapı maliyeti ve karmaşıklığı azalır, geliştirme yaşam döngüsü sadeleşir ve hızlanır
3 yorum
Kuruluş içinde bir staging ortamı kurarken hissettiğim güven duygusunu düşününce buna pek katılamıyorum.
Buna rağmen deploy sürecinin gecikmesi ya da değişikliklerin birikmesi gibi dezavantajlara katılıyorum.
Bence sadece staging ortamının var olması bile, başka bir ortama deploy edilebildiğini ve kopyalanabilir yazılımın doğasını gerçekten karşılayıp karşılamadığını doğrulama açısından anlamlı.
Açıkçası, bunun "sahiplik" / "özen" açısından eksik olan insanlara bel bağlanacak bir iş olup olmadığından emin değilim. En azından söylenen şeyi kusursuzca yerine getiren bilgisayarlardan yardım almak, bilgisayar programcılarının yapması gereken bir şey değil mi?
Ayrıca kavramı genişleterek
staging = nihai onay için (konuştuğumuz spesifikasyonla sonunda aynı mı, prodükt verisini koyunca düşünüldüğünden daha çirkin görünüyor mu vb. kontroller için)
dev = geliştiriciler ve benzeri kişilerle personel ve feature hakkında tartışma için (demo amaçlı)
şeklinde kullanıyoruz.
Hmm.. Bence bu tür konular, hangi tür hizmet geliştirdiğinize göre değişir.
Ne kadar test ederseniz edin sorun çıkabilir; önemli olan, kullanıcıların bunu kabul edip edemeyeceğini değerlendirmektir.
Facebook gibi, yanlış çalışsa da insanların "olur böyle şeyler" diyebildiği yazılımlarda bu tür bir yaklaşım mümkün olabilir.
Ama görev açısından kritik altyapılarda ya da ücretli hizmetlerde, sorun çıkmaması için elden gelen her türlü önlemi almak gerekir.