Vibe coding ile oluşturulmuş bir uygulama ne zaman taşınmalı?

Oluşturulmuş bir uygulamayı yayına almadan önce taşımak daha ucuz ve daha temizdir. Kullanıcı kazandıktan sonra taşımak daha çok bilgiye dayanır, ancak hata payı çok daha düşüktür. Doğru zaman, projenin Lovable, Bolt, v0 veya Replit’te başlamasından çok, mevcut platformun sahip olduğu her durum tutan sınırı adlandırıp prova edip edemediğinize bağlıdır.

Yayını, kimlik, veri ve herkese açık alan adının kullanıcılara verilen sözlere dönüştüğü an olarak görürüm. Bu noktadan önce, başarısız bir geçiş geliştirici zamanına mal olur. Sonrasında aynı hata müşterileri dışarıda bırakabilir, kayıtları kaybettirebilir, oturumları geçersiz kılabilir veya trafiği ürünün iki farklı sürümüne yönlendirebilir. Kullanıcı kazanımı, neyin korunmaya değer olduğuna dair kanıt sağlar; sıradan bir kod taşımasını operasyonel bir değişime de dönüştürür.

Kararı kaynak ağacının boyutuna göre vermeyin. Yönetilen kimlik doğrulaması ve canlı veritabanı olan küçük bir uygulamayı taşımak, büyük bir statik siteden daha zor olabilir. Sahipliğe göre karar verin: Depoyu, kullanıcı kimliklerini, veritabanını, gizli anahtarları, dosyaları, zamanlanmış işleri, alan adını, dağıtımı ve geri alma yolunu kim kontrol ediyor?

Yayından önce geçiş size özgürlük kazandırır

Mevcut platform sahiplik, dağıtım, veri konumu veya sürdürülebilirlik için bilinen bir gereksinimi karşılayamıyorsa, yayından önce geçiş yapmak genellikle daha iyi seçimdir. Şemaları değiştirmek, kimlik doğrulamayı yenilemek, ortam değişkenlerini yeniden adlandırmak ve test verilerini kullanıcılarla uzlaşmak zorunda kalmadan sıfırlamak için hâlâ alanınız vardır.

Bu aşama özellikle uygulamada yalnızca başlangıç hesapları ve silinebilir kayıtlar varsa caziptir. Kodu dışa aktarabilir, temiz bir ortamda derleyebilir, veritabanını geçişlerden yeniden oluşturabilir ve hangi parçaların ilk çalışma alanında örtük kaldığını keşfedebilirsiniz. Her başarısızlık değerlidir, çünkü bir bağımlılık müşteri verisi taşımaya başlamadan önce onu görünür kılar.

Uygun zamanlama, işi isteğe bağlı hâle getirmez. Oluşturulmuş projeler çoğu zaman ilk platformları yapılandırma eklediği, veritabanı URL’si sağladığı, işlevleri barındırdığı veya bir derleme kuralını anladığı için çalışır. Kaynak kod dışa aktarımı, dosyalara sahip olduğunuzu kanıtlar. Başka bir ana makinenin aynı sistemi derleyip çalıştırabileceğini kanıtlamaz.

Yayından önce temiz ortam testi isterim. Projeyi oluşturmamış bir ekip arkadaşı yalnızca depoyu, güvenli geliştirme değerleri içeren yazılı gizli anahtar listesini ve kurulum talimatlarını alır. Bu kişi çalışan bir girişe ulaşamıyor, kayıt oluşturamıyor ve ana kullanıcı yolculuğunu tamamlayamıyorsa proje henüz taşınabilir değildir.

Ertelemek için de geçerli nedenler vardır. Erken aşamadaki bir prototipin veri modeli her gün değişebilir ve bir sonraki ürün kararıyla geçiş çalışması çöpe gidebilir. Mevcut platform hedeflenen yayını, kaynak kod dışa aktarımını, dağıtımı, özel alan adlarını ve inandırıcı bir geri alma yolunu destekliyorsa, küçük bir sürümden öğrenmek kimsenin istemediği bir ürün için altyapıyı parlatmaktan daha değerli olabilir.

Bu nedenle yayın öncesindeki karar “Taşıyabilir miyiz?” değildir. “Taşınmak bilinen bir yayın riskini ortadan mı kaldırıyor, yoksa tahminleri korumak için mi ödeme yapıyoruz?” sorusudur. Somut bir kısıt için geçiş yapın. Geleneksel altyapı daha saygın hissettiriyor diye geçiş yapmayın.

Kullanıcı kazanımı, kanıtla birlikte yükümlülük de getirir

Kullanıcı kazandıktan sonra geçiş yapmak, gerçek kullanım ilk kurulumun karşılayamadığı ihtiyaçları ortaya çıkardıysa mantıklıdır. Ancak plan, hâlihazırda kullanılan her herkese açık sözü korumalıdır. Artık yoğun kullanılan yolları, gerçek veri hacmini, kullanıcıların tetiklediği arka plan işlerini ve hangi entegrasyonların önemli olduğunu bilirsiniz. Bu kanıt, hayali bir mimariye doğru pahalı bir geçişi önleyebilir.

Yükümlülükler de aynı derecede somuttur. Mevcut parolalar çalışmaya devam etmeli veya kullanıcılar için kontrollü bir sıfırlama yolu bulunmalıdır. URL’ler, faturalar, web kancaları veya yabancı anahtarlar onları açığa çıkarıyorsa veritabanı tanımlayıcıları sabit kalmalıdır. Yüklenen dosyalar için aktarım planı gerekir. E-posta bağlantıları ve OAuth geri çağrıları doğru alan adına gitmelidir. Kopyalama sırasında yapılan yazmalar yeni veritabanına ulaşmalı ya da bilinçli olarak duraklatılmalıdır.

Kullanıcı kazanımı tek bir eşik değildir. Uygulamayı bordro için kullanan on etkin müşteri, statik bir kataloğu okuyan on bin kişiden daha yüksek geçiş riski yaratır. Hesapları değil, durumu ve sonuçları sayın. Dakikada ne kadar verinin değiştiğini, yinelenen bir işlemin ne kadar maliyetli olduğunu, desteğin etkilenen her kullanıcıya ne kadar hızlı ulaşabileceğini ve işletmenin bakım penceresine ne ölçüde dayanabileceğini sorun.

Bu aşamada ekipler gözlemlenen talebi mimari izinle de karıştırır. Daha fazla kullanıcı, yeniden yazımı kendiliğinden haklı çıkarmaz. Dışa aktarılan uygulama anlaşılabiliyorsa ve mevcut hizmetler her seferinde bir sınır ayrılarak ayrıştırılabiliyorsa, tüm yığını değiştirmek yerine kademeli geçiş daha güvenlidir.

Kullanıcı kazanımı sonrasındaki bir geçişi onaylamadan önce yazılı bir sahiplik haritası isterim:

• Kaynak depo ve derleme süreci
• Kullanıcı dizini ve etkin oturumlar
• Ana veritabanı, dosyalar ve yedekler
• Gizli anahtarlar, zamanlanmış işler ve giden web kancaları
• Alan adı, e-posta gönderici kayıtları, izleme ve geri alma yetkisi

Boş kalan her madde bir engeldir, geçiş gecesine bırakılacak ayrıntı değildir. Platformun adı, yalnızca bu varlıklardan birini nasıl dışa aktaracağınızı veya yeniden yapılandıracağınızı değiştirdiğinde önem taşır.

Kimlik doğrulama, kimliklerin taşınmasıdır

Kimlik doğrulama, daha sonra yeniden yapılabilecek bir giriş ekranı olarak değil, kimliklerin ve güven kurallarının aktarımı olarak ele alınmalıdır. Görünen form kolay kısımdır. Parola karmaları, sağlayıcı konu kimlikleri, doğrulanmış e-posta durumu, çok faktörlü kimlik doğrulama kaydı, kurtarma yöntemleri, oturumlar ve yetkilendirme rolleri asıl sürekliliği taşır.

Önce uygulamanın kendi kullanıcı tablosuna mı sahip olduğunu, yoksa kimliği yönetilen bir hizmete mi devrettiğini belirleyin. Kullanıcıları dışa aktarabiliyorsanız hangi alanların kullanılabildiğini ve parola karmalarının hedefe içe aktarılıp aktarılamadığını inceleyin. İki sistem de onlara karma adını veriyor diye karmalar birbiriyle uyumlu değildir. Hedef sistem tam algoritmayı ve parametreleri desteklemelidir, yoksa tüm parolalar sıfırlanmalıdır.

Sosyal giriş, başka bir kimlik birleşim noktası oluşturur. OAuth sağlayıcıları genellikle sağlayıcıya özgü sabit bir konu tanımlayıcısı döndürür. Yeni uygulama hesapları yalnızca e-posta ile eşleştirirse, adresler değiştiğinde veya sağlayıcılar farklı takma adlar döndürdüğünde kişileri yanlışlıkla birleştirebilir. Veren kuruluş, sağlayıcı konusu ve yerel kullanıcı kimliği üçlüsünü koruyun. Geçişten önce geri çağrı URL’lerini yeniden kaydedin, ardından hem yeni girişi hem de mevcut bir hesabı test edin.

OWASP’ın Oturum Yönetimi Hile Sayfası, yetki değişikliğinden sonra oturum tanımlayıcısının yenilenmesini önerir. Geçiş kendi başına bir yetki değişikliği değildir; ancak bu öneri önemli bir sınırı gösterir: Oturum durumu güvenlik durumudur. Bir kimlik doğrulama yığınından diğerine şeffaf olmayan çerezleri serileştirmeye çalışmak genellikle kötü bir pazarlıktır. Tam olarak anlıyorsanız eski doğrulayıcıyı geçici olarak tutun veya oturumları sonlandırıp kullanıcılara yeniden giriş yapmaları gerektiğini söyleyin. Yeni hizmetin doğrulayamadığı bir çerezi asla sessizce kabul etmeyin.

Çerez kapsamı, başka açılardan doğru olan bir geçişi bozabilir. Yeni ana makinenin ürettiği çerez adını, alan adını, yolu, Secure, HttpOnly ve SameSite özniteliklerini kontrol edin. MDN’nin Set-Cookie başvurusu, Domain özniteliği olan bir çerezin o alan adı ve alt alan adlarında kullanılabildiğini; alan adı belirtilmediğinde ise çerezi ayarlayan ana makineyle sınırlı kaldığını açıklar. Eski uygulama web arayüzü için bir ana makine, API için başka bir ana makine kullandıysa bu ayrım önemlidir. Eski bir çerezin yeni akış sağlıklıymış gibi görünmesine yol açmaması için yeni bir tarayıcı profilinde test edin.

Yetkilendirme ayrı bir karşılaştırmayı hak eder. Kullanıcı başarıyla kimlik doğrulasa da kuruluş üyeliğini, yönetici rolünü, abonelik hakkını veya satır düzeyindeki politikasını kaybedebilir. Farklı rollere sahip hesaplardan bir örnek dışa aktarın ve veriyi taşımadan önce beklenen erişim testleri yazın. Başarılı giriş sayfası neredeyse hiçbir şeyi kanıtlamaz.

Yayın öncesi geçişte kimlik sistemini şimdi değiştirmeyi ve test kullanıcılarını silmeyi tercih ederim. Kullanıcı kazanımı sonrasında ise açık bir süreklilik stratejisi seçin:

• Uyumlu parola karmalarını içe aktarın ve sağlayıcı kimliklerini koruyun.
• Uygulama taşınırken eski kimlik hizmetini kullanmaya devam edin.
• Süresi dolan, tek kullanımlık belirteçlerle sıfırlama isteyin.
• Yazma işlemleri için tek bir yetkiliyle kısa süreli çift okuma köprüsü çalıştırın.

Yazılabilir iki kullanıcı dizini çalıştırmayın. Çakışan e-posta değişiklikleri ve hesap silme talepleri bu kolaylığı kısa sürede olaya dönüştürür.

Veritabanı aktarımı anlamı korumalıdır

Veritabanı geçişi, hedef sistem kısıtlamaları, tanımlayıcıları, zaman damgalarını, ilişkileri ve taşıma sırasında kabul edilen her yazmayı koruduğunda başarılı olur. Satır sayıları zayıf bir kontroldür. İki veritabanı aynı satır sayısına sahipken para hassasiyeti, saat dilimleri, benzersizlik, boş değer işleme veya yabancı anahtarlar konusunda farklılaşabilir.

Yayından önce geliştirme veritabanını kopyalamak yerine veritabanını sürümlü geçişlerden yeniden oluşturun. Yalnızca uygulamanın gerektirdiği kayıtları ekleyin. Bu test, şema geçmişinin eksiksiz olduğunu ve uygulamanın barındırılan konsolda birinin elle oluşturduğu tablolara bağlı olmadığını kanıtlar.

Kullanıcı kazanımından sonra şema taşımasını canlı veri taşımasından ayırın. Kaynak motoru ve sürümünü, uzantıları, harmanlamaları, üretilen sütunları, tetikleyicileri, satır düzeyindeki politikaları, dizileri ve büyük nesneleri kaydedin. Hedef farklı bir veritabanı motoru kullanıyorsa bunu uygulama geçişi olarak da ele alın. SQL söz dizimi bu değişimin en küçük parçasıdır; çirkin sürprizleri işlem davranışı ve tür anlamları yaratır.

PostgreSQL belgeleri pg_dump aracını, okuyucuları veya yazıcıları engellemeyen tutarlı bir dışa aktarım olarak tanımlar. Bu yararlıdır, ancak ekipler çoğu zaman bu sözü gereğinden fazla yorumlar. Tutarlı anlık görüntü, anlık görüntü başladıktan sonra tamamlanan yazmaları içermez. Bu boşluğu kapatmak için yine de değişiklik yakalama yöntemi, son yazma duraklatması veya bakım penceresi gerekir.

Geçiş kaydıyla birlikte çıktısı saklanabilecek bir mutabakat sorgusu kullanın. Bu parça, üç önemli tablo için sayıları, tanımlayıcı sınırlarını ve güncelleme pencerelerini kontrol eder:

SELECT 'users' AS table_name, count(*) AS rows,
       min(id)::text AS min_id, max(id)::text AS max_id,
       max(updated_at) AS newest_update
FROM users
UNION ALL
SELECT 'projects', count(*), min(id)::text, max(id)::text, max(updated_at)
FROM projects
UNION ALL
SELECT 'orders', count(*), min(id)::text, max(id)::text, max(updated_at)
FROM orders;

Bunu iki tarafta da çalıştırın ve her farkı inceleyin. Ardından sayıların göremediği alan kurallarını test edin: Hiçbir sipariş eksik kullanıcıyı göstermemeli, bakiyeler defterleriyle eşleşmeli, her dosya kaydının bir nesnesi olmalı ve benzersizlik kuralları aynı yinelenen kayıtları reddetmelidir.

Yedeklerin geri yükleme testine ihtiyacı vardır. Başarılı bir dışa aktarma dosyası yalnızca bir komutun bittiğini gösterir. Dosyayı boş bir hedefe geri yükleyin, uygulamayı ona karşı çalıştırın ve süreci zamanlayın. Ölçülen geri yükleme süresi, geri yüklemeyle geri almanın gerçekçi mi yoksa yalnızca rahatlatıcı mı olduğunu gösterir.

Dosya depolama alanı çoğu zaman veritabanı satırlarının arkasında gizlenir. Dışa aktarılan bir uploads tablosu nesne adlarını korurken asıl nesneler platform tarafından yönetilen bir pakette kalabilir. Baytları, sağlama toplamlarını, içerik türlerini, erişim kurallarını ve sahiplik meta verilerini kopyalayın; ardından indirmeleri depolama konsolu yerine uygulama üzerinden örnekleyin. URL’lerde imzalı belirteçler veya eski ana makine adı varsa eski URL’leri kopyalamak yerine yeniden üretin. Kullanıcı yüklemelerini, kullanıcıların veritabanı kopyası çalışırken dosya değiştirebildiği durumlarda özellikle, aynı geçiş penceresindeki durum olarak ele alın.

Ortam değişkenleri gizli mimariyi ortaya çıkarır

Ortam değişkenlerini devralınmış bir dize torbası olmaktan çıkarıp her ortam için adlandırılmış bir sözleşmeye dönüştürün. Eksik değişkenler belirgin hatalara yol açar. Daha tehlikeli olanlar, test ödeme anahtarı, eski web kancası sırrı veya kullanıcıları eski ana makineye gönderen geri çağrı kökeni gibi makul görünen ama yanlış üretim değerleri içerir.

Değişkenleri koddan, platform ayarlarından, derleme yapılandırmasından, sunucusuz işlevlerden, zamanlanmış işlerden ve dağıtım sisteminden envantere alın. Eski ortamın tamamını yeni ana makineye kopyalamayın. Her değeri sahibine, hassasiyetine, kapsamına, döndürme yöntemine ve derleme zamanında mı çalışma zamanında mı okunduğuna göre sınıflandırın.

Kısa bir bildirim dosyası sınırı incelenebilir kılar:

DATABASE_URL          runtime   secret   owner=backend   rotate=yes
PUBLIC_APP_ORIGIN     build     public   owner=web       rotate=no
SESSION_SIGNING_KEY   runtime   secret   owner=security  rotate=yes
MAIL_SENDER           runtime   public   owner=ops       rotate=no
WEBHOOK_SECRET        runtime   secret   owner=backend   rotate=yes

Derleme zamanı ile çalışma zamanı ayrımı, React tarzı ön yüzlerde önemlidir. Derleme sırasında gömülen bir değer, biri çalışma zamanı ayarını değiştirdiğinde değişmez. İstemciyi yeniden derleyin ve teslim edilen pakette herkese açık yapılandırmayı inceleyin. Bir değişkenin adı çerçevenin genel önekiyle başlıyor diye ona asla gizli bir anahtar koymayın.

Hedef sistem bir örtüşme dönemi destekliyorsa kullanıcı kazanımı sonrasındaki geçişte gizli anahtarları döndürün. Web kancası doğrulaması veya oturum imzalama için, yalnızca yenisini verirken eski ve yeni sırrı kısa süre kabul edin. Eski değeri, en uzun teslimat veya oturum penceresinden sonra kaldırın. Sağlayıcı yalnızca tek bir sırrı destekliyorsa, geçişi son kesmeyle koordine edin ve bu bağımlılığı çalışma kitabında açıkça belirtin.

Yayın öncesinde kullanılmayan değişkenleri silin ve gerekli değerler eksikse uygulamanın başlamasını engelleyin. Kullanıcı kazanımından sonra, temizlikten önce gözlemlenebilirlik ekleyin; böylece görünüşte kullanılmayan bir entegrasyonun hâlâ çağrı alıp almadığını görebilirsiniz. Değişken adlarından tahmin yürütmek, ekiplerin finansın aslında ihtiyaç duyduğu sessiz aylık işi devre dışı bırakmasının yoludur.

Değerleri ortama göre karşılaştırın, ancak gizli anahtarları geçiş belgesine asla yapıştırmayın. Gizli anahtar adlarını ve sürüm etiketlerini kaydedin, değerleri ise hedef sistemin gizli anahtar deposunda tutun. Uygulama kimliğine yalnızca o dağıtımın ihtiyacı olan değerleri okuma izni verin. Bir değişken değiştiğinde kimin değiştirdiğini ve hangi sürümün kullandığını kaydedin. Bu küçük disiplin, geçiş gecesindeki tanıdık soruyu yanıtlar: “Aslında hangi veritabanı URL’sini dağıttık?”

Alan adı geçişi trafik kontrolü değişikliğidir

Bir alan adı geçişi, DNS yayılımı sırasında hem eski hem de yeni dağıtımın trafiği güvenle alabileceği şekilde tasarlanmalıdır. DNS her yerde aynı anda değişmez. Değişiklikten kısa süre önce yaşam süresini düşürmek, eski değeri zaten önbelleğe almış çözümleyicileri etkilemez.

Planlanan taşınmadan birkaç gün önce ilgili kaydın TTL’sini düşürün ve yetkili yanıtı doğrulayın. Eski dağıtımı en az önceki TTL süresi ve ihtiyatlı bir çözümleyici payı boyunca sağlıklı tutun. Trafiği yönlendirmeden önce yeni ana makinede sertifikayı hazırlayın; kök alan adını, www ana makinesini, API alt alan adını, yönlendirmeleri ve IPv6 kayıtlarını ayrı ayrı doğrulayın.

Alan adı yalnızca giriş kapısıdır. Kimlik doğrulama geri çağrılarını, izin verilen kökenleri, çerez alan adlarını, kanonik URL’leri, web kancası uç noktalarını, e-posta bağlantılarını ve tüm mobil derin bağlantı yapılandırmalarını güncelleyin. Depoda ve platform ayarlarında eski ana makine adını arayın. Yönlendirme tarayıcılara yardımcı olur; ancak katı OAuth geri çağrı uyuşmazlığını veya yanlış uç nokta için imzalanmış bir web kancasını düzeltmez.

Sıfır kesinti, yalnızca iki sürümün uyumlu durumla çalışabilmesi hâlinde mümkündür. Yeni sürüm eski kodun okuyamadığı bir veritabanı değişikliği yapıyorsa DNS örtüşmesi hatalara yol açar. Genişlet ve daralt şema değişikliklerini kullanın: Önce yeni sütunu veya tabloyu ekleyin, her iki biçimi de anlayan kodu dağıtın, veriyi taşıyın, ardından tüm trafik eski sürümden ayrıldıktan sonra eski biçimi kaldırın.

Düşük hacimli ürünler için kısa bir bakım penceresi, karmaşık canlı çoğaltma kurulumundan daha güvenli olabilir. Yazmaların ne zaman duracağını söyleyin, uygun bir bakım yanıtı döndürün, arka plan işlerini boşaltın, son kopyayı alın, mutabakatı yapın, trafiği değiştirin ve yazmaları yeniden açın. Gizli iş kuyruğa ekleyemiyorsa salt okunur erişim açık kalabilir.

Geri almanın veri kuralı olmalıdır. Hedefe hiç yazma ulaşmadığında DNS’i geri yönlendirmek kolaydır. Kullanıcılar iki tarafta da yazma yaptıktan sonra DNS’i geri çevirmek veriyi atabilir veya çatallayabilir. Son güvenli geri alma anını tanımlayın. Bu andan sonra, trafik değişiminin tutarlılığı geri getirdiğini varsaymak yerine ilerleyin veya değişiklikleri mutabık hâle getirin.

Uygulamayı yeni barındırma hesabının dışından izleyin. Alan adını birden fazla genel çözümleyiciyle çözün, sertifika zincirini isteyin, sayfayı sıcak önbellek olmadan yükleyin, geri alınabilir bir işlem gönderin ve ortaya çıkan arka plan işinin bittiğini doğrulayın. Ana makine panoları sağlıklı dağıtım gösterebilirken kullanıcılar eski DNS yanıtı alabilir veya bölgesel bir uç nokta daha eski bir derleme döndürebilir. Örtüşme bitene kadar hem herkese açık alan adına hem de hedefe özgü test ana makinesine karşı sentetik bir kontrol çalıştırın.

Kaynak kod temizliği geçişin kalıcılığını belirler

Kaynak kod temizliği, yararlı oluşturulmuş yapıyı silmeden veya ilgisiz bir yeniden yazımı tetiklemeden platform bağımlılığını kaldırmalıdır. Oluşturulmuş kod tekrarlı veya hantal olabilir, ancak estetik beğenmemek geçiş gereksinimi değildir. Bağımsız derlemeyi, test etmeyi, güvenlik incelemesini veya gelecekteki bakımı engelleyen şeyleri değiştirin.

Kökenle başlayın. Tüm depoyu dışa aktarın ve lisans dosyalarını, varlık atıflarını, oluşturulmuş geçişleri, kilit dosyalarını ve yapılandırmayı saklayın. Gizli anahtarların veya platform belirteçlerinin Git geçmişine girip girmediğini kontrol edin. Bunları son dosyadan silmek erişimlerini iptal etmez. Bu nedenle açığa çıkan kimlik bilgilerini döndürün ve geçmişin yeniden yazılmasının gerekli olup olmadığına karar verin.

Ardından platforma özgü içe aktarımları, vekil yollarını, veritabanı istemcilerini, kimlik doğrulama yardımcılarını, depolama bağdaştırıcılarını, dağıtım dosyalarını ve oluşturulmuş API uç noktalarını bulun. Uygunsa bunları dar uygulama arayüzlerinin arkasında değiştirin. Depo genelinde arama yararlıdır, ancak kullanıcı yolculuklarını çalıştırmak hangi başvuruların hâlâ önemli olduğunu gösterir.

Bağımlılık temizliği, bağımsız derleme çalıştıktan sonra gelir. Paketleri tek tek kaldırın, mevcut paket yöneticisiyle kilit dosyasını yeniden oluşturun ve her gruptan sonra testleri çalıştırın. Çerçeveyi yükseltmeyin, durum yönetimini değiştirmeyin, her bileşeni yeniden adlandırmayın ve barındırmayı aynı değişiklikte taşımayın. Bu, tek bir hata için çok fazla açıklama yaratır.

Oluşturulmuş sunucu kodu güven sınırlarında daha yakından incelenmelidir. Her isteği rotadan yetkilendirme kontrolüne, oradan veritabanı sorgusuna kadar izleyin ve sunucunun istemci tarafındaki görünürlük kuralına dayanmadığını doğrulayın. Yükleme sınırlarını, giden istek hedeflerini, hata mesajlarını ve yönetim rotalarını inceleyin. Bu, oluşturulmuş her işleyiciyi yeniden yazma çağrısı değildir. Platform ara yazılımı ve yönetilen vekiller ortadan kalktıktan sonra kodun erişim kurallarını hâlâ uyguladığını doğrulamaya odaklı bir kontroldür.

Oluşturulmuş proje, sıradan operasyon dosyalarına da ihtiyaç duyar: Sahte değerlerle örnek ortam bildirimi, veritabanı geçiş komutları, derleme ve başlatma talimatları, sağlık kontrolleri ve arka plan çalışanlarının açıklaması. Bu talimatları çalıştırılabilir tutun. “Veritabanını yapılandırın” diyen bir README yalnızca bir veritabanının var olduğunu kaydeder.

Yayın öncesi temizlik, uyumluluk sözü olmadığı için şema sıfırlamalarını ve büyük yeniden düzenlemeleri içerebilir. Kullanıcı kazanımı sonrasındaki temizlik, altyapı geçişi oturana kadar herkese açık API biçimlerini, tanımlayıcıları ve kullanıcıya görünen davranışı korumalıdır. Ürün davranışını değiştirmeden önce yeni dağıtıma sakin bir dönem tanıyın. Geçiş ve yeniden tasarım birlikte geldiğinde, destek ekibi şikâyetin taşınmadan mı yeni özellikten mi kaynaklandığını anlayamaz.

Prova, kesintiyi karara dönüştürür

Geçiş provası, yakın tarihli ve gizliliği sağlanmış veri kopyasıyla üretim sırasını yeniden üretmeli; ölçülen süreler, mutabakat çıktısı ve test edilmiş bir iptal noktası sağlamalıdır. Başka bir projeden kopyalanmış kontrol listesi, veritabanınızın geri yüklenmesinin ne kadar sürdüğünü veya bakım modu başladıktan sonra hangi işin yazmaya devam ettiğini söyleyemez.

Bir operatör uygulamayı yapmalı, diğeri gözlemlemeli, süreleri kaydetmeli ve atlanan kontrolleri sorgulamalıdır. Küçük ekipte ikinci kişi kurucu olabilir, ancak değişen sonucu fark edecek kadar bağlama ihtiyaç duyar. Komutları yazan kişi, bu komutların işe yarayıp yaramadığına karar veren tek kişi olmamalıdır.

Pratik bir çalışma kitabının katı bir sırası vardır:

1. İlgisiz dağıtımları dondurun; mevcut sürümleri, DNS değerlerini ve gizli anahtar sürümlerini kaydedin.
2. Yazma işlemlerini bakım moduna alın, kuyrukları boşaltın, zamanlanmış işleri durdurun ve son kaynak işaretini kaydedin.
3. Kalan verileri kopyalayın, tabloları ve alan kurallarını mutabık hâle getirin, ardından kimlik doğrulama ve ana yolculuk testlerini çalıştırın.
4. Trafiği değiştirin, sertifikaları ve geri çağrıları doğrulayın, hataları ve kuyruk derinliğini izleyin, ardından yazmaları yeniden açın.
5. Bildirilen kontrol noktasında ya yeni sistemde devam edin ya da belgelenmiş geri alma veri kuralını uygulayın.

Yayından önce, hedefi yok edip depodan yeniden kurarak prova yapın. Hedef yeniden üretilebilirliktir. Bu yüzden boş veritabanı ve yeni ortam, üretime benzeyen bir kopyadan daha çok şey ortaya çıkarır.

Kullanıcı kazanımından sonra ölçeği ve eşzamanlılığı prova edin. Yavaş dizinleri ve uzun geçişleri ortaya çıkaracak kadar temsili veri kopyalayın. Varsa güvenli okuma trafiğini yeniden oynatın, bilinen tanımlayıcılarla sentetik yazmalar oluşturun ve yeniden denemelere izin vermeden önce arka plan işlerinin idempotent olduğunu doğrulayın. İki kez e-posta gönderen bir iş, veritabanı tutarlı kaldı diye zararsız değildir.

Yazma duraklatmasını tüm bakım penceresinden ayrı ölçün. Kaynak canlı kalırken toplu kopyalamayı çoğu zaman yapabilir, ardından yalnızca fark ve doğrulama için duraklatabilirsiniz. Prova, farkın izin verilen pencere içinde bitmeyeceğini gösterirse çoğaltma veya değişiklik yakalama ekleyin. Bu gereksinimi müşteriler beklerken keşfetmeyin.

Geçişten sonra kanıtları saklayın: Kaynak ve hedef sürümleri, zaman damgaları, satır kontrolleri, temel test sonuçları, DNS yanıtları, operatör kararları ve eski hizmetlerin devre dışı bırakıldığı zaman. Bu kayıt hata ayıklamayı hızlandırır ve sonraki geçiş planının birinin hafızasına bağlı olmasını önler.

Aşamayı geri alınabilirliğe göre seçin

En iyi geçiş aşaması, gerçekçi olarak neden olabileceğiniz hatanın hâlâ geri alınabilir olduğu aşamadır. Yayından önce ürünün az kanıtı vardır ama neredeyse sınırsız özgürlüğü vardır. Kullanıcı kazanımından sonra ürünün kanıtı vardır, ancak taşınma boyunca tutarlı kalması gereken durum taşır.

Altı karar testi kullanırım:

• Bilinen bir uyumluluk, sahiplik, dışa aktarma, barındırma veya mimari kısıt hedeflenen yayını engelliyorsa, yayından önce geçin.
• Platform mevcut ihtiyaçları karşılıyorsa ve ekip aksi hâlde yalnızca kaygıdan geçiş yapacaksa, kalın ve yayına çıkın.
• Ölçülmüş kullanım bir kısıtı ortaya çıkarıyorsa ve kimlik, veri ve trafik sürekliliğini prova edebiliyorsanız kullanıcı kazanımından sonra geçin.
• Geri yüklenebilir veritabanını dışa aktaramıyor, alan adını kontrol edemiyor, gizli anahtarları listeleyemiyor veya yazma sahipliğini tanımlayamıyorsanız erteleyin.
• Kimlik doğrulama veya veri, işlem gücü ve barındırma taşınırken geçici olarak kalabiliyorsa kademeli ayrıştırmayı tercih edin.

Lovable, Bolt, v0 ve Replit; seçilen tam hizmetlere, kullanılan plana ve o anda oluşturulan koda bağlı taşınabilirliği olan projeler üretebilir. Gerçek depoyu ve hesap kontrollerini inceleyin. Bir sağlayıcı kategorisi, sizin özel parola karmalarınızın, veritabanı uzantılarınızın, dosyalarınızın veya dağıtım ayarlarınızın taşınıp taşınamayacağını yanıtlamaz.

Yeni bir sohbet tabanlı geliştirme ortamı seçerseniz, planlama ve geri alma kontrolleri geçişi incelenebilir değişikliklere ayırmanın maliyetini düşürür. Koder.ai kaynak kod dışa aktarma, dağıtım ve barındırma, özel alan adları, anlık görüntüler ve geri almayı destekler. Böylece ekip, makalenin önerilerini tek bir platforma bağımlı kılmadan bu sahiplik kontrollerini geçiş planında tutabilir.

Kalma kararı verseniz bile yayından önce bir geçiş bütçesi belirleyin. Kaynak kodu kontrolünüz altında tutun, şemayı sürümlendirin, ortam sözleşmesini belgeleyin ve geri yüklemeyi prova edin. Uygulama küçükken bunların maliyeti çok daha düşüktür ve kullanıcı kazanımı kriz yerine gerekçe sağladığında taşınma seçeneğini korur.

Ekip bugün bu geri yüklemeyi yapamıyorsa taşınabilirlik, uygulamanın özelliği olmaktan çok bir niyet olarak kalır.