Yeniden üretme-güvenli şema evrimi ile öngörülebilir migrasyonlar

Yeniden üretilen backendlerle şema değişiklikleri neden riskli hissettirir

Görsel bir modelden backend yeniden üretildiğinde, bir veritabanı değişikliği kazağı çeken bir ipi çekmek gibi gelebilir. Data Designer'da bir alanı güncellersiniz, yeniden üret düğmesine basarsınız ve aniden sadece bir tabloyu değiştirmiyorsunuz. Aynı zamanda üretilen API'yi, doğrulama kurallarını ve uygulamanızın veri okuma/yazma için kullandığı sorguları da değiştiriyorsunuz.

Çoğunlukla yanlış giden şey yeni kodun derlenememesi değildir. Birçok kodsuz platform (AppMaster dahil, gerçek Go kodu üreten) her seferinde temiz bir proje üretir. Asıl risk, üretimde zaten verinin bulunmasıdır ve verinin otomatik olarak sizin yeni fikrinize uyması beklenmemelidir.

İnsanların ilk fark ettiği iki başarısızlık basittir:

• Bozuk okumalar: bir sütun taşındı, bir tür değişti ya da sorgu artık orada olmayan bir şeyi bekliyor ve uygulama kayıtları yükleyemiyor.
• Bozuk yazmalar: yeni veya güncellenmiş kayıtlar, kısıtlamalar, zorunlu alanlar veya formatlar değiştiği için başarısız oluyor; mevcut istemciler hâlâ eski biçimi gönderiyor.

Her iki hata da acı vericidir çünkü gerçek kullanıcılar karşılaşana kadar gizlenebilirler. Bir staging veritabanı boş veya yeni doldurulmuş olabilir, bu yüzden her şey yolunda görünür. Prodüksiyonun kenar durumları vardır: sizin varsaydığınız değerlerin olmadığı null'lar, eski enum stringleri veya yeni kuraldan önce oluşturulmuş satırlar.

İşte bu yüzden yeniden üretme-güvenli şema evrimi önemlidir. Amaç, backend kodu tamamen yeniden üretildiğinde bile her değişikliğin güvenli olmasıdır; böylece eski kayıtlar geçerli kalır ve yeni kayıtlar yine de oluşturulabilir.

“Öngörülebilir migrasyonlar” demek, dağıtımdan önce dört soruyu yanıtlayabiliyor olmanız demektir: veritabanında ne değişecek, mevcut satırlara ne olacak, dağıtım sırasında hangi uygulama sürümü çalışmaya devam edebilir ve beklenmedik bir durum çıkarsa nasıl geri alınır.

Basit bir model: şema, migrasyonlar ve yeniden üretilen kod

Platformunuz backend'i yeniden üretebildiğinde, kafanızda üç şeyi ayırmak faydalıdır: veritabanı şeması, onu değiştiren migrasyon adımları ve üretimde zaten duran canlı veriler. Bunları karıştırmak değişiklikleri öngörülemez kılar.

Yeniden üretimi “en son modelden uygulama kodunu yeniden inşa etmek” olarak düşünün. AppMaster gibi bir araçta bu yeniden üretim normal çalışma sırasında sık sık olabilir: bir alanı ince ayarlarsınız, iş mantığını düzeltirsiniz, bir endpoint ekler, yeniden üretir, test eder, tekrar. Yeniden üretim sık gerçekleşir. Üretim veritabanınız ise sık değişmemelidir.

Basit model şöyle:

• Şema: veritabanı tablolarınızın, sütunların, indekslerin ve kısıtların yapısı. Veritabanının beklediği şey budur.
• Migrasyonlar: şemayı bir sürümden diğerine taşıyan sıralı, tekrar çalıştırılabilir adımlar (bazen veri hareketi de yaparlar). Bunlar her ortamda çalıştırdıklarınızdır.
• Çalışma zamanı verisi: kullanıcılar ve süreçler tarafından oluşturulmuş gerçek kayıtlar. Değişiklik öncesinde, sırasında ve sonrasında geçerli kalmaları gerekir.

Yeniden üretilen kod "geçerli şema ile konuşan mevcut uygulama" olarak ele alınmalıdır. Migrasyonlar, kod değiştikçe şema ile çalışma zamanı verisini uyumlu tutan köprüdür.

Yeniden üretme oyunu neden değiştirir

Sık sık yeniden üretim yapıyorsanız, doğal olarak birçok küçük şema düzenlemesi yaparsınız. Bu normaldir. Risk, bu düzenlemelerin geriye dönük uyumlu olmayan bir veritabanı değişikliğini ima etmesi veya migrasyonunuzun deterministik olmaması durumunda ortaya çıkar.

Pratik bir yönetim yolu, yeniden üretme-güvenli şema evrimini küçük, geri alınabilir adımlar dizisi olarak planlamaktır. Tek bir büyük anahtar yerine, eski ve yeni kod yollarının kısa bir süre birlikte çalışmasını sağlayan kontrollü hamleler yaparsınız.

Örneğin, canlı bir API tarafından kullanılan bir sütunun adını değiştirmek istiyorsanız, hemen yeniden adlandırmayın. Önce yeni sütunu ekleyin, her iki sütuna da yazın, mevcut satırları doldurun, sonra okumaları yeni sütuna geçirin. Ancak ondan sonra eski sütunu kaldırın. Her adım test etmesi kolaydır ve bir şey ters giderse veriyi bozmadan duraklatabilirsiniz.

Bu zihniyet, kod yeniden üretimi günlük gerçekleşse bile migrasyonları öngörülebilir yapar.

Şema değişiklik türleri ve hangileri üretimi bozar

Backend'iniz en son şemadan yeniden üretildiğinde, kod genellikle veritabanının şu anda o şemayla eşleştiğini varsayar. Bu yüzden yeniden üretme-güvenli şema evrimi daha çok “Veri ve eski istekler değişiklik sırasında hayatta kalabilir mi?” sorusudur.

Bazı değişiklikler mevcut satırları veya sorguları geçersiz kılmadığı için doğal olarak güvenlidir. Diğerleri verinin anlamını değiştirir ya da çalışmakta olan uygulamanın hâlâ beklediği bir şeyi kaldırır; işte üretim olaylarının olduğu yer burasıdır.

Düşük riskli, genelde güvenli (eklemeli)

Eklemeli değişiklikler, eski veriyle birlikte var olabildikleri için en kolay yayımlananlardır.

• Henüz kimsenin bağımlı olmadığı yeni tablo.
• Varsayılan gerektirmeyen yeni nullable sütun.
• Sondan sona opsiyonel yeni API alanı.

Örnek: users tablosuna nullable bir middle_name sütunu eklemek genellikle güvenlidir. Mevcut satırlar geçerli kalır, yeniden üretilen kod var olduğunda okuyabilir, eski satırlarda sadece NULL olur.

Orta risk (anlam değişiklikleri)

Bu değişiklikler teknik olarak genelde “çalışır” ama davranışı bozar. Doğrulamalar, üretilen modeller ve iş mantığı varsayımları yeniden üretimle güncelleneceği için dikkatli koordinasyon gerekir.

Yeniden adlandırmalar klasik tuzaktır: phone'ı mobile_phone olarak yeniden adlandırmak, yeniden üretim sonrası kodun artık phone okumaması ve üretimde verinin hâlâ orada olmasıyla sonuçlanabilir. Benzer şekilde, birimi değiştirmek (fiyatın dolar yerine kuruş cinsinden saklanması) kodu veriden önce veya veriyi koddan önce güncellerseniz hesaplamaları sessizce bozabilir.

Enumlar da keskin bir kenardır. Enum'u daraltmak (değerleri kaldırmak) mevcut satırları geçersiz kılabilir. Enum'u genişletmek genelde güvenlidir ama tüm kod yollarının yeni değeri ele alabildiğinden emin olmalısınız.

Pratik yaklaşım: anlam değişikliklerini "önce ekle, sonra doldur, sonra değiştir, en sonunda kaldır" şeklinde ele alın.

Yüksek riskli (yıkıcı)

Sütun düşürme, tablo silme veya bir sütunu nullable'dan not-null'a çevirmek gibi değişiklikler genellikle hemen üretimi bozar, özellikle platform kodun eski biçimi beklemeyi bıraktığında.

Not-null değişikliği yapmanız gerekiyorsa, aşamalar halinde yapın: önce sütunu nullable olarak ekleyin, backfill yapın, uygulama mantığını artık bunu hep set edecek şekilde güncelleyin, sonra NOT NULL getirin.

Performans ve güvenlik değişiklikleri (yazmaları engelleyebilir)

İndeksler ve kısıtlamalar “veri şekli” değişikliği olmasa da yine de kesinti yaratabilir. Büyük bir tabloda indeks oluşturmak veya unique kısıtlama eklemek yazmaları kilitleyebilir ve zaman aşımına neden olabilir. PostgreSQL'de bazı işlemler çevrimiçi yöntemlerle daha güvenlidir, ama önemli nokta zamanlamadır: ağır işlemleri düşük trafikte yapın ve bir staging kopyasında ne kadar sürdüğünü ölçün.

Üretimde ekstra dikkat gerektiren değişikliklerde planlayın:

• Uyumluluğu koruyan iki aşamalı bir dağıtım (önce şema, sonra kod veya tersi).
• Partiler halinde çalışan backfill işler.
• Net bir geri alma yolu (yeniden üretilmiş backend erken canlıya alınırsa ne olur?).
• Verinin yeni kurallara uyduğunu kanıtlayan doğrulama sorguları.
• Temizlik işleminin aynı deploy içinde yapılmaması için "eski alanı sonra kaldır" bileti.

AppMaster gibi Data Designer'dan backend kodu üreten bir platform kullanıyorsanız, en güvenli bakış açısı şudur: eski verinin bugün yaşayabileceği değişiklikler gönderin, sonra sistem adapte olduktan sonra kuralları sıkılaştırın.

Yeniden üretme-güvenli değişiklikler için ilkeler

Yeniden üretilen backend'ler harikadır, ta ki bir şema değişikliği üretime inip eski satırlar yeni şekle uymayana kadar. Yeniden üretme-güvenli şema evriminin amacı basittir: veritabanınız ve yeniden üretilmiş kod birbirlerini küçük, öngörülebilir adımlarla yakalayana kadar uygulamanız çalışmaya devam etsin.

Varsayılan olarak “genişlet - göç et - daralt” yapın

Her anlamlı değişikliği üç hareket olarak ele alın. İlk önce şemayı genişletin ki hem eski hem yeni kod çalışabilsin. Sonra veriyi taşıyın. Sadece ondan sonra eski sütunları, varsayılanları veya kısıtları kaldırın.

Pratik kural: "yeni yapı" ve "kırıcı temizlik"i aynı dağıtımda birleştirmeyin.

Eski ve yeni şekilleri bir süre destekleyin

Aşağıdaki bir süre boyunca var olacağını varsayın:

• bazı kayıtların yeni alanları var, bazılarının yok
• bazı uygulama örnekleri eski kodu çalıştırıyor, bazıları yeniden üretilmiş kodu
• arka plan işler, içe aktarımlar veya mobil istemciler gecikebilir

Geçiş süresince her iki şeklin de geçerli olduğu bir veritabanı tasarlayın. Bu, örneğin AppMaster gibi bir platformda Data Designer'ı güncelleyip Go backend'i yeniden ürettiğinizde daha da önem kazanır.

Yazmalardan önce okumaları uyumlu hale getirin

Yeni kodun eski veriyi güvenle okuyabildiğinden emin olun. Ancak ondan sonra yazma yollarını yeni veri şekline geçiriniz.

Örneğin bir status alanını status + status_reason olarak böldüyseniz, önce yeni kodun eksik status_reason durumunu idare edebilmesini sağlayın. Sonra status_reason yazmaya başlayın.

Kısmi ve bilinmeyen verilerle ne yapacağınıza karar verin

Enumlar, not-null sütunlar veya daha sıkı kısıtlamalar eklerken, eksik veya beklenmeyen değerlerle ne olacağını baştan kararlaştırın:

• geçici olarak null'a izin verin, sonra backfill yapın
• anlamı değiştirmeyen güvenli bir varsayılan koyun
• okuma hatası vermemesi için bir "bilinmiyor" değeri tutun

Bu, sessiz bozulmayı (yanlış varsayılanlar) ve sert hataları (yeni kısıtlamaların eski satırları reddetmesi) önler.

Her adım için bir geri alma hikâyesi hazırlayın

Geri alma en kolay genişletme aşamasında olur. Geri almanız gerekirse, eski kod genişletilmiş şema ile çalışmaya devam etmelidir. Geri alma (sadece kod mu yoksa kod artı migrasyon mu) için ne yapacağınızı yazın ve yıkıcı değişikliklerden önce geri alma ihtimalini düşük hissetmeden emin olmayın.

Adım adım: yeniden üretmeyi atlatacak bir değişikliği planlayın

Yeniden üretilen backend'ler affetmez: şema ile üretilen kod uyuşmazsa üretim bunu genellikle önce bulur. En güvenli yaklaşım her değişikliği küçük, geri alınabilir bir yayılma olarak ele almaktır, kodsuz araçlarla bile.

Önce niyeti basit bir dille yazın ve verilerinizin bugün nasıl göründüğünü not edin. Üretimden 3–5 gerçek satır seçin (veya yeni bir dump'tan) ve düzensiz kısımları işaretleyin: boş değerler, eski formatlar, şaşırtıcı varsayılanlar. Bu, gerçek verinin karşılayamayacağı mükemmel bir yeni alan tasarlamanızı engeller.

AppMaster gibi bir platformda Go backend servislerini Data Designer modelinden yeniden ürettiğinizde işe yarayan pratik sıra:

1. Önce genişletin, değiştirmeyin. Yeni sütunları veya tabloları ekleyin. Yeni alanları ilk etapta nullable yapın veya yeni satırlar için güvenli varsayılanlar verin. Yeni bir ilişki getiriyorsanız, yabancı anahtarın boş olmasına izin verin ta ki doldurulana kadar.

2. Hiçbir şeyi kaldırmadan genişletilmiş şemayı dağıtın. Veri tabanı değişikliğini, eski kod hala çalışırken yayınlayın. Amaç: eski kod eski sütunlara yazmaya devam edebilsin ve veritabanı bunu kabul etsin.

3. Kontrollü bir iş ile backfill yapın. Yeni alanları dolduran, izlenebilir ve yeniden çalıştırılabilir (idempotent) bir toplu işlem çalıştırın. Tablo büyükse yavaş yavaş yapın ve kaç satır güncellendiğini kaydedin.

4. Önce okumaları değiştirin, yedeklemesi olsun. Yeniden üretilmiş mantığı yeni alanları tercih edecek şekilde güncelleyin ama yeni veri eksikse eski alanlara geri dönsün. Okumalar stabil olduktan sonra yazmaları yeni alanlara geçirin.

5. En son temizlik yapın. Güvenceye (ve bir geri alma planına) sahip olduktan sonra eski alanları kaldırın ve kısıtları sıkılaştırın: NOT NULL ekleyin, unique ekleyin, yabancı anahtarları uygulayın.

Somut örnek: serbest metin status sütununu statuses tablosuna işaret eden status_id ile değiştirmek istiyorsunuz. status_id'yi nullable olarak ekleyin, mevcut metin değerlerden backfill yapın, uygulamayı status_id okumak için güncelleyin ama null ise statusa geri dönsün, sonra statusu düşürüp status_id'yi zorunlu yapın. Bu, veritabanının her aşamada uyumlu kalmasını sağlar.

Yeniden kullanabileceğiniz pratik desenler

Backend'iniz yeniden üretildiğinde, küçük şema değişiklikleri API'lerde, doğrulamalarda ve UI formlarında dalga etkisi yaratabilir. Amaç, eski verilerin geçerli kalmasını sağlarken yeni kodun devreye girmesidir.

Desen 1: Kırmayan yeniden adlandırma

Doğrudan yeniden adlandırma risklidir çünkü eski kayıtlar ve eski kod genelde orijinal alanı bekler. Daha güvenli yaklaşım kısa bir migrasyon dönemidir.

• Yeni sütunu (customer_phone) ekleyin, eski sütunu (phone) tutun.
• Kaydettiğinizde her iki alana da yazacak şekilde mantığı güncelleyin (dual-write).
• Mevcut satırları backfill yaparak customer_phone ile doldurun.
• Okumaları yeni sütuna geçin ve ardından eski sütunu sonraki sürümlerde kaldırın.

Bu, AppMaster gibi yeniden üretimin veri modellerini ve endpoint'leri güncelleyeceği araçlarda iyi çalışır. Dual-write, geçiş sırasında her iki kod jenerasyonunu da memnun eder.

Desen 2: Bir alanı ikiye bölme

full_name'i first_name ve last_name yapmak benzer ama backfill daha karmaşıktır. Orijinal alanı tamamen kaldırmadan tutun.

Pratik kural: original alanı, her kayıt ya backfill edilene kadar ya da açık bir fallback bırakılana kadar kaldırmayın. Eğer ayrıştırma başarısız olursa, tüm stringi last_name'e koyup kaydı incelenmek üzere işaretleyin.

Desen 3: Alanı zorunlu yapmak

Nullable bir alanı required yapmak klasik bir üretim kırıcıdır. Güvenli sıra: önce backfill, sonra enforcement.

Backfill otomatik olabilir (güvenli bir varsayılan koymak) veya iş odaklı olabilir (kullanıcılardan eksik verileri doldurmalarını istemek). Veriler tamamlanmadan NOT NULL ve doğrulamaları eklemeyin. Yeniden üretilen backend daha sıkı doğrulamalar ekliyorsa, bu sıra sürpriz hataları önler.

Desen 4: Enum'u güvenli değiştirme

Enum değişiklikleri, eski kod eski değerleri gönderdiğinde kırılır. Geçiş sırasında her iki değeri de kabul edin. pending yerine queued koyuyorsanız, her iki değeri de kısa süreliğine geçerli tutun ve mantığınızda haritalayın. Eski değer artık gönderilmediğinden emin olduktan sonra kaldırın.

Eğer değişiklik tek bir sürümde gitmek zorundaysa, riski azaltmak için etki alanını daraltın:

• Yeni alanlar ekleyin ama eski alanları tutun.
• Insert'lerin çalışması için bir veritabanı varsayılanı kullanın.
• Kod toleranslı olsun: yeni alandan oku, yoksa eskine dön.
• Geçici bir eşleme katmanı ekleyin (eski değer girildiğinde yeni değere dönüştürülüp saklansın).

Bu desenler, yeniden üretilen kod davranışı hızlı değişse bile migrasyonları öngörülebilir kılar.

Sürprizlere yol açan yaygın hatalar

En büyük sürprizler, insanların kod yeniden üretimini sihirli bir sıfırlama düğmesi gibi görmesiyle olur. Yeniden üretilen backend'ler uygulama kodunuzu temiz tutar ama üretim veritabanınız hâlâ dünün verilerini, dünün şeklinde tutar. Yeniden üretme-güvenli şema evrimi, yeni üretilecek kodu ve tabloda oturmuş eski kayıtları birlikte planlamaktır.

Yaygın tuzaklardan biri platformun "migrasyonlarla ilgileneceğini" varsaymaktır. Örneğin AppMaster'da Data Designer modelinden Go backend yeniden üretebilirsiniz, ama platform gerçek müşteri verisini nasıl dönüştürmek istediğinizi tahmin edemez. Yeni bir zorunlu alan eklediyseniz, mevcut satırların nasıl bir değer alacağı konusunda net bir plana ihtiyacınız vardır.

Diğer bir sürpriz, alanları veya isimleri çok erken silmek ya da yeniden adlandırmaktır. Bir alan ana UI'da kullanılmıyor gibi görünebilir, ama bir rapor, zamanlanmış bir export, bir webhook handler veya nadiren açılan bir admin ekran tarafından hâlâ okunuyor olabilir. Testte güvenli görünen değişiklik, prodüksiyonda bir unutulmuş yol nedeniyle başarısız olabilir.

Gece yarısı geri alma gerektiren beş hata:

• Şemayı değiştirip kodu yeniden üretmek ama eski satırları geçerli kılacak veri migrasyonunu hiç yazmamak veya doğrulamamak.
• Bir sütunu yeniden adlandırmak veya silmek ama her okuyucu ve yazıcının güncellenip dağıtılmasını beklememek.
• Büyük bir tabloda backfill yapmadan önce sürenin ne kadar olacağını ve yazmaları engelleyip engellemeyeceğini kontrol etmemek.
• Yeni bir kısıtlama (NOT NULL, UNIQUE, foreign key) ekleyip sonra legacy verinin bunu kırdığını fark etmek.
• Arka plan işler, exportlar ve raporları unutmak; bunlar hâlâ eski alanları okuyor olabilir.

Basit bir senaryo: phone'ı mobile_number olarak yeniden adlandırıp NOT NULL ekliyorsunuz ve yeniden üretiyorsunuz. Uygulama ekranları çalışıyor gibi gözükebilir ama eski CSV export hâlâ phone seçiyor ve binlerce kaydın mobile_number değeri null. Çözüm genelde adım adım değişikliktir: yeni sütunu ekleyin, bir süre her iki alana da yazın, güvenli backfill yapın, sonra kısıtlamaları sıkılaştırıp eski alanı kaldırın.

Daha güvenli migrasyonlar için hızlı dağıtımdan önce kontrol listesi

Backend'iniz yeniden üretildiğinde kod hızla değişebilir ama üretim verisi sürprizlere izin vermez. Bir şema değişikliği göndermeden önce kısa bir "bu güvenli şekilde başarısız olabilir mi?" kontrolü yapın. Bu, yeniden üretme-güvenli şema evrimini sıkıcı kılar (ki arzu edilen budur).

Çoğu problemi yakalayan 5 kontrol

• Backfill büyüklüğü ve hızı: kaç satırın güncelleneceğini tahmin edin ve prodüksiyonda ne kadar süreceğini hesaplayın. Küçük veritabanında kısa olan bir backfill, gerçek veride saatler sürebilir.
• Kilitleme ve kesinti riski: değişiklik yazmaları engelleyebilir mi? Büyük tabloları değiştirmek veya türleri değiştirmek uzun kilitlere yol açabilir. Herhangi bir risk varsa daha güvenli bir dağıtım planlayın.
• Eski kod vs yeni şema uyumluluğu: eski backend kısa süreliğine yeni şema ile çalışabilir mi? Eğer çalışmazsa, iki aşamalı sürüm gerekir.
• Varsayılanlar ve null davranışı: yeni sütunlar için mevcut kayıtlar ne olacak? NULL mu, yoksa bir varsayılan mı? Mantığınız eksik değerleri normal karşılayabilmeli.
• İzleme sinyalleri: dağıtımdan sonra bakacağınız kesin alarmları seçin: hata oranı, yavaş DB sorguları, kuyruk/iş hataları ve önemli kullanıcı eylemleri. Ayrıca doğrulama hatalarındaki ani artış gibi "sessiz" hatalara da bakın.

Hızlı bir örnek

orders tablosuna yeni required bir status alanı ekliyorsanız, bunu tek seferde "NOT NULL, varsayılan yok" şeklinde göndermeyin. Önce nullable olarak ekleyin, yeni satırlar için bir varsayılan koyun, yeniden üretilmiş kodu eksik status'u idare edecek şekilde dağıtın, eski satırları backfill edin, sonra kısıtlamayı sıkılaştırın.

AppMaster'da bu zihniyet özellikle faydalıdır çünkü backend sık yeniden üretilebilir. Her şema değişikliğini küçük bir sürüm gibi ele alın ve geri alma planınız, temiz izleme ve geçmesi gereken kontroller olsun; böylece migrasyonlar öngörülebilir kalır.

Örnek: canlı bir uygulamayı mevcut kayıtları bozmadan evrimleştirmek

Bir destek aracında ajanlar biletlere priority adında serbest metinle öncelik etiketi atıyor olabilir (örnekler: high, urgent, HIGH, p1). Raporlar ve yönlendirme kuralları için sıkı bir enum'a geçmek istiyorsunuz.

Güvenli yaklaşım, eski kayıtları geçerli tutarken backend yeniden üretilirken iki sürümlü bir değişikliktir.

Sürüm 1: genişletin, her iki alanı da yazın ve backfill yapın

Şemayı genişleterek başlayın. priority_enum gibi yeni bir enum alanı ekleyin (low, medium, high, urgent). Orijinal priority_text alanını tutun.

Sonra yeni ve düzenlenen biletlerin her iki alana da yazılmasını sağlayacak mantığı ekleyin. AppMaster gibi kodsuz bir araçta bu genellikle Data Designer modelini ve Business Process'i güncellemek anlamına gelir; input'u enum'a eşleyip orijinal metni de saklarsınız.

Ardından mevcut biletleri küçük partiler halinde backfill edin. Yaygın metin değerlerini enum'a eşleyin (p1 ve urgent -> urgent, HIGH -> high). Bilinmeyenler geçici olarak medium'a atanabilir ve sonra el ile incelenir.

Kullanıcıların gördüğü şey: ideal olarak hiçbir şey değişmez. UI aynı kalabilir, ama arka planda yeni enum dolduruluyor. Raporlar backfill başlar başlamaz enum'u kullanmaya başlayabilir.

Sürüm 2: daraltın ve eski yolu kaldırın

Güven kazandıktan sonra okumaları sadece priority_enum'a geçirin, filtreleri ve dashboard'ları güncelleyin, sonra priority_text'i ilerleyen bir migrasyonda kaldırın.

Sürüm 2'den önce küçük bir örnekle doğrulayın:

• Farklı ekiplerden ve farklı yaşlardaki 20–50 bileti seçin.
• Görünen öncelik ile saklanan enum değeri karşılaştırın.
• Enum değerlerine göre sayımlarda anormal sıçramalar olup olmadığına bakın (ör. çok fazla medium).

Sorun çıkarsa, geri alma kolaydır çünkü Sürüm 1 eski alanı korudu: Sürüm 1 mantığını yeniden dağıtın ve UI'yi priority_text okumaya geri çevirin, eşlemeyi düzeltip backfill'i tekrar çalıştırın.

Sonraki adımlar: şema evrimini tekrarlanabilir bir alışkanlık haline getirin

Öngörülebilir migrasyon istiyorsanız, şema değişikliklerini küçük bir proje gibi ele alın, hızlı bir düzenleme gibi değil. Amaç basit: her değişiklik açıklanması kolay, prova edilmesi kolay ve kazara kırması zor olsun.

Görsel bir veri modeli etkiyi dağıtımdan önce görünür kıldığı için yardımcı olur. Tabloları, ilişkileri ve alan türlerini bir yerde görebildiğinizde, bir script'te kaçırılabilecek şeyleri fark edersiniz: güvenli bir varsayılanı olmayan bir zorunlu alan veya eski kayıtları yetimsiz bırakacak bir ilişki gibi. "Buna kim bağlı?" sorusunu: API'ler, ekranlar, raporlar ve arka plan işler olarak hızla kontrol edin.

Kullanımda olan bir alanı değiştirmeniz gerektiğinde kısa bir geçiş dönemi ve çoğaltılmış alanları tercih edin. Örneğin phone_raw tutup phone_e164 ekleyin, bir-iki sürüm boyunca okuyucu yeni alandan, yoksa eski alandan alsın; yazma iki alana da yapılsın; sonra eski alan tamamen dolduğunda kaldırın.

Ortam disiplini, iyi niyetleri güvenli sürümlere dönüştürür. Dev, staging ve production'ı hizalı tutun ama aynı görmeyin.

• Dev: yeniden üretilmiş backend'in temiz başlayıp temel akışların çalıştığını doğrulayın.
• Staging: tam migrasyon planını üretime benzeyen veride çalıştırın ve ana sorguları, raporları ve importları doğrulayın.
• Production: geri alma planı, net izleme ve birkaç "başarı kriteri" ile dağıtın.

Migrasyon planınızı gerçek bir doküman haline getirin, kısa olsa bile. İçerikte: ne değişiyor, sıra, backfill nasıl yapılacak, nasıl doğrulanacak ve nasıl geri alınacak yazsın. Sonra bunu bir test ortamında uçtan uca çalıştırın.

AppMaster kullanıyorsanız, Data Designer'dan görsel olarak faydalanın ve yeniden üretimin backend kodunuzu şema ile tutarlı kılmasına izin verin. Öngörülebilirliği sağlayan alışkanlık, migrasyonları açık hale getirmektir: hızlı iterasyon yapabilirsiniz, ama her değişiklik yine de mevcut üretim verisi için planlı bir yola sahip olmalıdır.