Firebase’den aşamalı geçiş rehberi

Kimler için?

Mobil uygulama ve backend geliştiren ekipler.

Başlamadan önce

Kendi staging ortamınız, örnek kullanıcı akışı ve erişim modeli.

1. Mevcut bağımlılıkları haritalayın

Firestore koleksiyonlarını, Security Rules kurallarını, Auth sağlayıcılarını, Functions tetikleyicilerini, Storage dosyalarını ve offline davranışı listeleyin. Hangi parçanın maliyet ürettiğini faturayla eşleştirin; hepsini taşımak zorunda olduğunuzu varsaymayın.

2. SQL veri modelini ve erişim kurallarını hazırlayın

Doküman ilişkilerini tablo, anahtar ve indekslerle ifade edin. Eski doküman ID’lerini geçiş eşlemesinde koruyun. Security Rules davranışını API yetkilendirmesine taşıyın; sadece endpoint’i gizlemek yeterli değildir.

3. Kimliği kontrollü taşıyın

Kullanıcı ID’leri, sosyal giriş bağlantıları ve mevcut parola doğrulama biçimleri yeni Auth tasarımıyla uyumlu olmalıdır. Oturum sürekliliğini test edin; uygun değilse kontrollü yeniden giriş veya şifre yenileme akışı belirleyin. Kullanıcı şifrelerini açık metne dönüştürmeyin.

4. Küçük bir pilot akış seçin

Örneğin herkese açık katalog okumasını sürümlü bir REST endpoint’ine taşıyın. Önce export edilmiş veriyle ve izole ortamda test edin. Mobil istemcinin hata, offline, sayfalama ve güncelleme davranışlarını doğrulayın.

5. Kesim ve geri dönüş planını sınayın

Tam aktarım sonrası artımlı değişikliklerin nasıl taşınacağını belirleyin. Kayıt sayısı, önemli alanlar ve izin sonuçlarını karşılaştırın. Çift yazma kullanılıyorsa çatışma ve başarısızlık riskini ele alın; geri dönüş koşullarını önceden tanımlayın.

6. Sağlam parçaları koruyun

FCM veya Crashlytics gibi mevcut araçlar hibrit mimaride kalabilir. Uygulama Cloud bugün yönetilen Firebase geçişi veya hazır Firebase uyumlu SDK sunmaz. Bu rehber planlama içindir; üretim veri aktarımı burada otomatik çalıştırılmaz.

7. Belge modelini ilişkisel şemaya dönüştürün

Firestore koleksiyonunu tek bir JSON kolona taşımak erişim ve sorgu ihtiyaçlarını çözmeyebilir. Belge kimliklerini, alt koleksiyonları, tekrar eden alanları ve uygulama referanslarını çıkartın. Bir kullanıcıya ait not örneğinde kullanıcı ilişkisi, tenant, oluşturma zamanı ve sürüm alanı ayrı tasarlanabilir. Veriyi dönüştürürken null, eksik alan, timestamp ve silme davranışını açıkça belirleyin.

Export almak SQL import sürecinin tamamı değildir. Gerekli dönüştürme işini staging’de tekrar çalıştırılabilir hale getirin. Aynı kaynak kimliğinin ikinci çalışmada duplicate üretmemesi için mapping ve benzersizlik kuralı kullanın.

8. Kimlik ve güvenlik kurallarını yeniden doğrulayın

Mevcut kullanıcı kimliklerini uygulama verisindeki referanslarla eşleyin. Parola veya oturumların hedef sistemde aynı biçimde kullanılabileceğini varsaymayın; desteklenen taşıma yollarını ve gerekirse yeniden giriş planını kontrol edin. Security Rules içindeki erişim kuralı yeni API veya SQL politikasına taşınmalıdır. İki kullanıcıyla okuma, yazma ve dosya erişimi test edin.

9. Cutover ve geri dönüş koşullarını yazın

Tek yönlü aktarım, kısa yazma duraklatması veya kontrollü çift yazma seçeneklerinden birini seçin. Çift yazmada iki sistemin kısmi başarısını toparlamak ayrı bir iştir. Pilot süresince kayıt sayısı, örnek değerler, dosya referansları ve ekran davranışını karşılaştırın. Geri dönüşte yeni yazıların eski sisteme nasıl taşınacağını bilmeden iki sistemi canlı açmayın.