Kişisel sitem için yürüttüğüm içerik taşınma süreci hakkında hızlı bir geliştirme günlüğü (davdevs-laravel): Düz dosya Astro içerik deposundan, PostgreSQL destekli bir Laravel uygulamasına geçiş yapıyorum; medya için Cloudinary kullanıyorum.
Harcanan gün (bir nevi)
Harcanan gün (bir nevi)
Bütün bir günü .md kılavuz belgeleri yazmaya harcadım — Claude Code’un göçü otonom olarak yönetmesi için adım adım talimatlar hazırladım.
Ertesi gün, taze bir gözle gözden geçirdiğimde, tüm planın yanlış bir topolojiye dayandığını fark ettim: Hem eski hem de yeni repo şu anda geliştirme makinemde olduğu için yerel-yerel bir transfer olarak tasarlamıştım. Ancak gerçek göç hedefi yerel-bulut (medya için Cloudinary, veri için barındırılan Postgres) ve bu sıralama, doğrulama ve geri alma işlemlerini oldukça değiştirdi. Orijinal belgeleri olduğu gibi kurtarmak mümkün olmadı. Bugünün commit’leri bu hikayeyi oldukça doğrudan anlatıyor:
- Göç belgelerini güncelledim
- Görüntüleri denetlemek için göç planını güncelledim
- feat: İçerik göç denetimi + içe aktarma komutları (Aşama 22, adım 1)
Ayrıca, Claude Code’un bu tür bir göçü baştan sona ne kadar düzgün gerçekleştireceğinden hala biraz şüpheliyim — ince içerik bozulmaları gözden kaçabilir — bu yüzden görüntü içe aktarıcıyı tekrar başlayabilir ve dosya bazında hatalara dayanıklı hale getirdim. (Make migration:import-images resumable and resilient to per-file failures), tüm süreci tek bir büyük atomik iş olarak ele almak yerine. Eğer 500 dosyadan 340. dosya üzerinde hata alırsam, baştan başlamayı istemem.
Gerçek tasarım kararları gerektiren iki içerik türü
Gerçek tasarım kararları gerektiren iki içerik türü
1. React bileşenleriyle ekli araç sayfaları
1. React bileşenleriyle ekli araç sayfaları
Her /tools gönderisinde yanında gömülü bir React bileşeni var. Claude Code’a verilen talimatlar dar bir çerçeveye sahipti:
- Yalnızca /tools içindeki bileşenleri taşımak
- Yeni siteye uygun bir renk düzeni güncellemeleri — örneğin, mavi butonların yerine sarı butonlar
Araçlar için React Bileşen Yöneticisi eklendi.
2. E-kitap ürün sayfaları (her bir e-kitaba özel tasarlanmış)
2. E-kitap ürün sayfaları (her bir e-kitaba özel tasarlanmış)
Bu daha zordu. Her e-kitap ürün sayfası, bireysel olarak tasarlanmıştı — özel lansmanlar için harika, ancak ham kodu saklanabilir DB kayıtlarına göç ederken kötü.
Çözüm: Her sayfayı benzersiz olarak ele almayı bırakmak. Tüm e-kitap ürün sayfalarını iki düzen varyantına birleştirmek — bireysel ve paket — ve yayınlama modülünü bu iki varyant içinde tam tasarım özelleştirmesini destekleyecek şekilde uyarlamak. Bu, araçlar için yapılan çalışma ile aynı commit’te yer aldı — 87346c7: Araçlar için React Bileşen Yöneticisi + E-kitaplar için Yayınlama Şablon Yöneticisi eklendi.
Bu durum, önceki aşamalardan gelen daha uzun bir mimariye dayanmaktadır — yayın yöneticisi, taksonomi CRUD, başsız REST API, JSON-LD/OG etiketleri — bu nedenle şablon birleştirme mevcut içerik modeline uyum sağlıyor. Bu, yeni bir ekleme değil, mevcut bir yapıya entegre ediliyor.
Kaynak: Orijinal Makale
