Ah şu deployment’lar yok mu… Bazen hayatın cilvesi gibi, tam her şey yolunda gidiyor derken, bir anda başınıza gelen en olmadık şeyle sizi sınar.
Geçenlerde başımıza gelen bir ‘Yanlış Deploy’ vakası var ki, anlatırken hala gülüyorum kendi halime. Production ortamına attığımız yeni bir özellik, ne güzel değil mi? Her şey test edilmiş, onaylanmış, adeta ‘kusursuz’ denilerek yola çıkmış.
Ama işte, teknoloji denen bu acayip dünya, bazen senin kusursuz dediğin şeye öyle bir tekme atar ki, ne olduğunu anlayamazsın bile.
Bilirsiniz, bu tür durumlarda ilk tepki hep panik olur. Production! Canlı! Müşteriler etkileniyor! Ama bizim ekip bu sefer sakin kalmayı başardı, ya da en azından dışarıdan öyle göründüler diyeyim. Rollback planımız hazırdı, her ihtimali düşünmüştük. En kötü senaryo, bir önceki stabil sürüme dönmekti. Ne kadar güzel bir fikir değil mi?
Neyse efendim, deploy tamamlandıktan kısa bir süre sonra ilk alarm zilleri çalmaya başladı. Kullanıcılardan gelen raporlar, beklediğimizden çok daha farklıydı. “Neler oluyor ya?” diye birbirimize baktığımızı hatırlıyorum. Sanki bizim deploy ettiğimiz kod, Production ortamına hiç uğramamış gibiydi. Her şey olduğu gibi çalışıyordu, ama aynı zamanda da her şey olması gerektiği gibi çalışmıyordu. Garip bir durumdu açıkçası.
Tam o sırada, ilk şokun ardından aklımıza gelen o meşhur soru: “Rollback yapalım mı?” diye düşündük. Her şey hazır, düğmeye basmak yeterliydi. Ama işte, tam o anda o belirsizlik ifadesi devreye girdi. 15-20 dakika kadar sürdü galiba bu tereddüt. Acaba sorun bizim kodda mıydı, yoksa altyapısal bir şey miydi? Yoksa… başka bir şey miydi?
Ve işte o an, olayın asıl komedisi ortaya çıktı. Meğer business tarafındaki arkadaşlar, Production’daki bir veritabanı tablosunu, bizim deploy ettiğimiz kodla aynı anda değiştirmişler. Ne güzel değil mi? Yani bizim kodumuz aslında gayet güzel çalışıyordu ama, karşı tarafta değişen tablo yapısı yüzünden her şey birbirine girmişti. Bizim deploy aslında ‘başarısız’ değildi, sadece doğru zamanda doğru yerde değildi.
Bu durum, bana uzun yıllar önce yaşadığım bir anıyı hatırlattı. C# ile bir Windows uygulaması geliştiriyordum. O zamanlar daha acemi sayılırım, her şeyi en ince detayına kadar düşünmeye çalışırdım. Bir raporlama modülü yazmıştım, kullanıcılar çok beğenmişti. Sonra bir gün biri geldi, “Abi bu rapor niye böyle?” dedi. Bir baktım, rapor aslında doğru çalışıyor ama, raporun çıktığı Excel dosyası… Aman Allah’ım! Kullanıcının Excel’de sayfa düzenini değiştirmiş olması yüzünden tüm rapor altüst olmuştu.
Bu hikayeyi neden anlattım? Çünkü bazen sorun, yazdığımız kodda değil, onunla etkileşime giren dış etkenlerde olabiliyor. Ya da bazen bizim ‘hatalı deploy’ dediğimiz şey, aslında farklı ekiplerin aynı anda yaptığı değişikliklerin birleşiminden kaynaklanabiliyor. Bu yüzden, üretim ortamında yapılacak her türlü değişikliğin, özellikle de veritabanı şeması gibi kritik yerlerdeki değişikliklerin, deploy süreçleriyle senkronize olması gerektiğini bir kez daha anladım.
Şimdi gelelim bu işin teknik kısmına. Rollback yapmadan önce, sorunun kaynağını hızlıca tespit etmek adına ne gibi adımlar izledik? Öncelikle, Production’daki logları didik didik inceledik. Hangi serviste ne zaman hata almışız, hangi kullanıcıdan ne gelmiş, hepsini bir kenara not aldık. Sonra, deploy ettiğimiz kodun hangi veritabanı tablolarına dokunduğunu kontrol ettik. Bu arada, o veritabanı tablosunu değiştiren ekiple de hemen iletişime geçtik tabii ki.
İşte o an, sorunun kaynağını bulduğumuzda hepimiz derin bir nefes aldık. Production’daki tablo yapısı bizim beklediğimizden farklıydı. Yani bizim kodumuz, olmayan bir sütuna veri yazmaya çalışıyordu, haliyle hata veriyordu. Rollback yapmak yerine, veritabanı değişikliğinin geri alınmasını ve bizim kodun tekrar deploy edilmesini sağladık. Ve bu sefer her şey tıkır tıkır işledi. Ne güzel değil mi?
Bu olayı atlattıktan sonra, aklıma gelen bir diğer önemli nokta da, ‘Feature Flag’ kullanımı oldu. Eğer daha önce bu konuda bir şeyler okuduysanız, ne demek istediğimi anlarsınız. Feature Flag’ler sayesinde, yeni özellikleri Production’a deploy edip, ama henüz aktif etmeden bekletebiliyorsunuz. Böylece, eğer bir sorun olursa, sadece bir ayarı değiştirerek özelliği devre dışı bırakabiliyorsunuz. Bu, rollback yapmaktan çok daha hızlı ve risksiz bir çözüm sunuyor bana göre. Bu konuda daha detaylı bilgi için Google’da küçük bir arama yapabilirsiniz.
Bu tür olaylar gerçekten insanın ufkunu açıyor. Bir yandan “Ah be, niye daha dikkatli olmadık?” diye düşünürken, diğer yandan da “Neyse ki büyük bir sorun yaşanmadı” diyorsunuz. Production ortamında yaşanan her hata, aslında gelecekteki daha büyük hataların önüne geçmek için bir ders niteliği taşıyor. Bu yüzden, bu tür ‘yanlış deploy’ senaryolarını birer kabus olarak değil, öğrenme fırsatı olarak görmek lazım.
Bu arada, bu yaşadığımız durum üzerine ekipçe bir toplantı yaptık. Bundan sonra, veritabanı değişikliklerinin ve uygulama deploy’larının aynı anda yapılmaması, birbiriyle senkronize bir şekilde ilerlemesi konusunda sıkı kararlar aldık. Hatta, bu süreci otomatikleştirecek bir pipeline bile düşündüğümüzü söyleyebilirim. Bu konuda daha fazla bilgi için YouTube’da bazı CI/CD pipeline örneklerine bakabilirsiniz.
Sonuç olarak, Production’a bir şeyler deploy etmek her zaman heyecan verici ama aynı zamanda da dikkat gerektiren bir süreç. En iyi planlar bile bazen beklenmedik sürprizlerle karşılaşabilir. Önemli olan, bu sürprizlere hazırlıklı olmak, hızlıca adapte olabilmek ve her olaydan bir ders çıkarmaktır. Tabi, ekibinizin sağlam olması da işin en önemli parçası. 🙂
Neyse efendim, bazen böyle teknik konulara dalıp gidiyorum işte. Bu arada, Bursa’da hava bugün çok güzel, güneşli. Akşama eşimle birlikte sahile inmeyi planlıyoruz. Belki bir kahve içer, sohbet ederiz. Hayat işte, hem kod yazıyoruz hem de ailemizle vakit geçirmeye çalışıyoruz.
Teknik bir fail hikayesi mi demiştim? Evet, geçenlerde bir devre tasarımı yaparken, yanlış bir transistör seçimi yüzünden tüm devrenin performansı düştü. O kadar uğraşmıştım ki, sonunda hatayı bulduğumda hem utandım hem de bir ders çıkardım. İşte o gün, veri sayfalarını (datasheet) ne kadar dikkatli okumam gerektiğini bir kez daha anladım. Sanırım o gün 5 saatimi sadece o hatayı bulmak için harcadım.