Yazılımın kodunu değiştirmek, yanlış giderse geri almak görece kolaydır: Önceki sürüme dönülür. Veritabanı şeması ise farklıdır. Bir sütun silindiğinde, bir tablo yeniden düzenlendiğinde ya da bir veri dönüşümü uygulandığında geri dönüş her zaman mümkün olmayabilir. Acente yazılımında bu veri; müşteri kayıtları, poliçe geçmişi, teklifler ve tahsilat bilgileri demektir. Şema migrasyonları, bu nedenle en dikkatli planlanması gereken değişiklik türlerinden biridir.
Migrasyon nedir ve neden kodla birlikte yönetilir?
Migrasyon, veritabanı şemasını bir durumdan diğerine taşıyan, sıralı ve tekrar çalıştırılabilir bir değişiklik betiğidir. Migrasyonların uygulama koduyla aynı depoda tutulması ve aynı inceleme sürecinden geçmesi, şemanın hangi durumda olduğunu her zaman izlenebilir kılar. Her ortam, hangi migrasyonların kendisinde uygulandığını kaydeder; böylece geliştirme, hazırlık ve canlı ortamlar arasında şema farkı oluşmaz.
Kesinti yaratan migrasyonların ortak noktası
Bir migrasyonun kesintiye yol açmasının iki temel nedeni vardır. Birincisi, uzun süren kilitler: Büyük bir tabloda yapılan bazı değişiklikler, tamamlanana kadar tabloya yazmayı ya da okumayı engelleyebilir. İkincisi, kod ile şema arasındaki uyumsuzluk: Yeni şema canlıya çıktığı anda hâlâ çalışan eski kod, artık var olmayan bir sütunu aramaya başlar.
Genişlet ve daralt deseni
Kesintisiz migrasyonun en güvenilir yolu, değişikliği birden fazla adıma bölmektir. Örneğin müşteri tablosundaki tek bir telefon alanını, birden fazla iletişim bilgisi tutabilen ayrı bir yapıya taşımak istediğimizi düşünelim.
- Genişlet: Yeni yapı eklenir; eski alan yerinde kalır. Bu adım hiçbir mevcut kodu bozmaz.
- Çift yazma: Uygulama kodu, yeni kayıtları hem eski alana hem yeni yapıya yazacak şekilde güncellenir.
- Geriye dönük doldurma: Mevcut kayıtlar, küçük gruplar hâlinde ve sistemi yormadan yeni yapıya kopyalanır.
- Okumayı taşıma: Kod, veriyi artık yeni yapıdan okur. Eski alan yazılmaya devam eder; geri dönüş hâlâ mümkündür.
- Daralt: Bir süre sorunsuz çalıştıktan sonra eski alana yazma durdurulur ve eski alan kaldırılır.
Bu yöntem, her adımın ayrı bir yayın olmasını gerektirir ve toplamda daha uzun sürer. Ancak her adım geri alınabilir ve hiçbir an kodla şema uyumsuz kalmaz.
Büyük tablolarla çalışmak
Teklif geçmişi ya da işlem kayıtları gibi zamanla büyüyen tablolarda bazı işlemler beklenenden çok daha uzun sürebilir. Bu tür tablolarda:
- Değişikliğin hazırlık ortamında, canlıya yakın hacimde maskeleme uygulanmış veriyle denenmesi,
- Veri dönüşümlerinin tek seferde değil, küçük partiler hâlinde yapılması,
- Dizin eklemenin, tabloyu kilitlemeyen yöntemlerle gerçekleştirilmesi,
- İşlemin, kullanımın düşük olduğu saatlere planlanması
riski önemli ölçüde azaltır.
Geri alma planı
Her migrasyon için "bu değişiklik geri alınabilir mi?" sorusu baştan cevaplanmalıdır. Yeni bir tablo ya da sütun eklemek kolayca geri alınabilir. Veri silmek ya da birleştirmek ise genellikle geri alınamaz. Geri alınamaz adımlardan önce ilgili verinin yedeğinin alındığından ve geri yükleme yönteminin denendiğinden emin olmak gerekir. Geri alma betiği yazılmışsa, o da hazırlık ortamında en az bir kez çalıştırılmalıdır.
Branş verilerinde özen
Acente yazılımında trafik, kasko ve DASK teklifleri farklı alanlar taşır. Trafik ve kasko araç bilgisine, DASK ise adres ve yapı bilgisine dayanır. Bu farklılık şema tasarımında da korunmalıdır. Tüm branşları tek bir geniş tabloda toplamak yerine ortak alanları ayrı, branşa özgü alanları ayrı tutmak, bir branş için yapılan migrasyonun diğerlerini etkileme riskini azaltır.
Migrasyon inceleme listesi
- Bu migrasyon çalışırken eski kod sorunsuz çalışmaya devam eder mi?
- Hangi tablolar kilitlenir ve ne kadar süreyle?
- Canlıdaki veri hacmiyle denendi mi?
- Geri alma yolu nedir ve denendi mi?
- Veri dönüşümü varsa, sonuç nasıl doğrulanacak?
Acenteler için anlamı
Şema migrasyonları acente kullanıcısının hiç görmediği ama verinin bütünlüğünü doğrudan etkileyen işlemlerdir. Müşteri geçmişinin eksiksiz kalması, eski tekliflerin doğru görüntülenmesi ve raporların tutarlı olması, migrasyonların ne kadar özenle yönetildiğine bağlıdır. CRM verisinin yıllar içinde biriken değeri, bu özenle korunur. Acente yazılımı seçerken, sağlayıcının veri yapısı değişikliklerini nasıl yönettiğini sormak bu nedenle anlamlıdır.
Migrasyonları yayın hattında çalıştırmak
Migrasyonların bir geliştiricinin elle veritabanına bağlanıp çalıştırdığı komutlar olmaktan çıkması, güvenliğin önemli bir adımıdır. Yayın hattına entegre edilmiş migrasyonlar için bazı kurallar faydalıdır:
- Sıra: Genişletme adımları uygulama kodundan önce, daraltma adımları ise kod artık eski yapıyı kullanmadığından emin olunduktan sonra çalışır.
- Tekrar çalıştırılabilirlik: Bir migrasyon yarıda kesilirse, yeniden çalıştırıldığında tutarlı bir sonuç üretmelidir.
- Kilit zaman aşımı: Migrasyon beklenenden uzun süre kilit bekliyorsa, kullanıcı isteklerini bloke etmek yerine kendini iptal etmeli ve ekibe haber vermelidir.
- Tek yetkili süreç: Birden fazla sunucu aynı anda başlatıldığında migrasyonun yalnızca bir kez çalışması garanti edilmelidir.
Bu kurallar, migrasyonu sıradan bir yayının öngörülebilir bir parçası hâline getirir ve gece yarısı yapılan riskli manuel işlemlere olan ihtiyacı azaltır.
Her migrasyonun yayın hattındaki çıktısının saklanması, yani hangi adımın ne kadar sürdüğünün ve kaç kaydı etkilediğinin kayda geçmesi, bir sonraki benzer değişikliğin planlanmasında değerli bir referans olur. Bu kayıtlar, büyüyen tablolarda işlemlerin zamanla nasıl uzadığını da gösterir ve hangi tabloların özel bir migrasyon stratejisi gerektirdiğini önceden belirlemeyi sağlar.
Sonuç
Güvenli şema migrasyonu, büyük değişiklikleri küçük ve geri alınabilir adımlara bölmekle başlar. Genişlet-daralt deseni, büyük tablolar için kademeli işlem ve önceden denenmiş geri alma planları, kullanıcıyı kesintiye uğratmadan ve veriyi riske atmadan şemanın gelişmesini sağlar.