Production’a bir şeyler deploy etmek, hele ki canlı sistemlere, her zaman heyecan vericidir. Hani böyle kodunu yazdın, testleri yaptın, her şey tıkırında görünüyor, sonra getirip o canlıya basıyorsun ya… İşte tam o an, böyle bir gergin tatlı bir bekleyiş olur insanda. Hele bir de o deploy senin için önemliyse, belki de aylarca üzerinde çalıştığın bir özelliğin canlıya çıktığı an… O anı bilirim ben.
Ama ne güzel değil mi? Kendi emeğinin karşılığını görmek, bir şeylerin çalışıyor olduğunu bilmek, hatta belki de kullanıcıların o yeni özellik sayesinde daha mutlu olduğunu düşünmek… İşte o an her şeye değer.
Fakat bazen, her şey planlandığı gibi gitmez. Hani o her şeyin yolunda gittiğini düşündüğün an vardır ya, işte tam orada bir şeyler ters köşe yapabilir. Production ortamı, sanki kendi kuralları olan bir varlık gibi davranabilir bazen. Ne kadar hazırlıklı olursan ol, ne kadar test edersen et, o ince detaylardan biri gözünden kaçabilir.
Ve işte o zaman, hayat sana roll-back dersin. Evet, tam olarak duyduğun gibi. Bir şeyler canlıda beklediğin gibi çalışmıyor, hatta belki de daha kötüsü, sistemin çökmesine neden oluyor. İşte o an, bütün o tatlı heyecan yerini acı bir duraksamaya bırakır. Geriye dönmek zorundasın. O son yaptığın deploy’u geri almak, her şeyi bir önceki stabil haline döndürmek.
Bu durumu şöyle düşünebiliriz; sanki bir yemek pişiriyorsun, her şeyi tam kıvamında yaptığını düşünüyorsun, tuzu, baharatı yerinde. Sonra tadına bakıyorsun, aman Allah’ım, bildiğin tuz basmışsın! Ne yapacaksın? O yemeği olduğu gibi servis mi edeceksin? Tabii ki hayır. Hemen o tencereyi kenara çekip, ilk yaptığın orijinal tarife dönmen gerekir. İşte rollback de tam olarak bu.
Neden peki böyle şeyler olur? Çoğu zaman, canlı ortamın kendine has dinamikleri, bilinmeyen bağımlılıklar veya sadece bizim göremediğimiz küçük bir hata yüzünden. Belki de bir veritabanı tablosunda beklenmedik bir veri var, belki de bir konfigürasyon ayarı farklı çalışıyor, kim bilir? Detayları tam olarak hatırlamıyorum ama sanırım birkaç yıl önce başıma gelmişti, bir mikroservis deploy’u sırasında, üretimdeki bir verinin formatı bizim local’dekine hiç uymuyordu. O gün, ne kadar dikkatli olmamız gerektiğini bir kez daha anladım.
Peki, bu roll-back süreci nasıl işler? Genellikle, eğer sisteminiz uygun bir şekilde tasarlanmışsa, bu süreç oldukça hızlı ve otomatiktir. Deploy ettiğiniz yeni versiyonun bir sağlık kontrolünden geçemediğini fark eden sistem, otomatik olarak önceki stabil versiyona geri döner. Ama tabii bu her zaman böyle sihirli bir şekilde olmaz. Bazen, bu süreç manuel müdahale gerektirebilir. Ekip olarak toplanıp, neyin yanlış gittiğini anlamaya çalışır, sonra da adım adım eski haline getiririz.
Bu arada, bu roll-back mantığı sadece yazılım deploy’larında değil, aslında birçok alanda karşımıza çıkabilir. Hani bazen bir ayarı değiştirirsin, her şey daha iyi olur dersin ama bir bakarsın sistem garip davranmaya başlamış, hemen eski ayarlara dönersin ya, işte o da bir nevi roll-back sayılır aslında.
Şimdi gelelim işin teknik kısmına. Bir roll-back stratejisi oluşturmak, aslında proaktif bir yaklaşım gerektirir. Yani, işler ters gittiğinde ne yapacağını bilmek, o an paniklemekten çok daha iyidir. Genellikle, CI/CD (Sürekli Entegrasyon / Sürekli Teslimat) pipeline’larımızda bu roll-back adımlarını da tanımlarız. Örneğin, bir deployment başarısız olduğunda, otomatik olarak önceki stabil sürüme geçiş yapacak şekilde ayarlarız. Bu, hem zaman kazandırır hem de insan hatası riskini azaltır.
Mesela, Git kullanıyorsanız, bu işler daha da kolaylaşır. Bir commit’i geri almak ne kadar kolaysa, bir deploy’u geri almak da o kadar basit hale gelebilir, tabii altyapınız uygunsa. İşte size basit bir örnek. Diyelim ki yanlış bir commit ile deploy yaptınız:
Önceki stabil sürümün commit ID’sini bulursunuz. Sonra da şu komutla o commit’e geri dönebilirsiniz:
`git revert <önceki_commit_id>`
Tabii bu sadece Git’in kendi içinde bir geri alma. Production ortamında ise bu işler biraz daha karmaşık olabiliyor. Kubernetes gibi araçlar, bu roll-back işlemlerini yönetmek için harika yetenekler sunuyor. Örneğin, bir deployment başarısız olduğunda, Kubernetes otomatik olarak önceki sürüme geri dönebilir. Bu, gerçekten büyük bir kolaylık sağlıyor, inanır mısın?
Şimdi, bu tür bir senaryoda, yani bir deploy’un başarısız olduğu ve roll-back yapılması gerektiği durumda, kodunuzun nasıl davranması gerektiği hakkında birkaç düşüncem var. En önemlisi, uygulamanızın durumu ne olursa olsun, bir şekilde bir “sağlık kontrolü” endpoint’i sunması. Bu endpoint, uygulamanın gerçekten çalışıp çalışmadığını, dış servislere bağlanıp bağlanamadığını vb. bildirir. Eğer bu endpoint hata verirse, sistem otomatik olarak bu deploy’u başarısız kabul edebilir.
Bir de şu var; eğer uygulamanızın içinde bir durum (state) tutuyorsa, bu durumu korumak veya eski haline döndürmek de önemli. Örneğin, bir kullanıcı profili güncellemesi yaptınız ama bu güncelleme bir şekilde bozuk çıktı. Roll-back yaptığınızda, o kullanıcının profilinin de eski haline dönmesi gerekir. Bu, veritabanı işlemleriyle, transaction’lar ile veya özel state migration mekanizmaları ile sağlanabilir. Açıkçası, bu kısım biraz daha karmaşık ve projenin mimarisine göre değişir.
Şöyle düşünelim, bir e-ticaret sitesinde yeni bir ödeme entegrasyonu deploy ettiniz. Her şey normal görünüyor. Fakat bir süre sonra, kullanıcılar ödeme yaparken sürekli hata almaya başladı. İşte tam bu noktada, o yeni ödeme entegrasyonunu hızla devre dışı bırakıp, eski çalışan yönteme dönmek şart. Yoksa, bütün satışlar durur, işler çok kötüye gider. Ne güzel değil mi, böyle bir geri dönüş mekanizmasının olması?
Tabii, bu roll-back senaryolarını yaşamamak için elimizden geleni yapıyoruz. Kapsamlı testler, kod incelemeleri, canary deployments gibi yöntemlerle riskleri minimize etmeye çalışıyoruz. Ama yine de, üretim ortamı sürprizlerle dolu bir yer. O yüzden, bir roll-back planınızın olması, bir nevi sigorta poliçesi gibidir. En kötü senaryoya hazırlıklı olmak, her zaman akıllıcadır.
Sonuç olarak, “Yanlış Deploy: Rollback Senaryosu” dediğimiz şey, aslında bizim üretim ortamındaki en büyük korkularımızdan biri. Ama aynı zamanda, iyi planlanmış bir sistemin ne kadar güçlü olabileceğini gösteren bir ders. Her zaman en iyisini umut edin, ama en kötüsüne de hazırlıklı olun. Bu arada, bu konuyu daha detaylı incelemek isterseniz, Kubernetes’in deployment stratejileri hakkında biraz araştırma yapabilirsiniz. Kubernetes Deployment dokümantasyonunda bu konu hakkında bolca bilgi bulabilirsiniz.