Geliştirmesini yaptığımız bir işte migration olduğu zaman github üzerinden revert edip o migrationların rollback edilmesini sağlayabilir miyim?
Burada aslında rollback yapma işini automatize etmeye çalışıyorum. Bunun için CIRCLE CI veya LAMBDA function mı kullanmam gerekiyor. Burada revert edilen migration numarasını alıp bir rollback mekanizması kurmak istiyorum revert içerisinde bir migration varsa.
Biraz araştırma yaptım ama bir sonuç bulamadım. Bu işin doğru yolu nedir kısmında takıldım
Migration’ların etkisiz olmasını sağlamak daha iyi bir çözüm olur.
Migration’ları mümkünse tek seferde değil, bölerek ilerlemek gerekir. Database tarafında yapılan kolon ekleme, kolon silme, backfill etme, rename etme işlemlerini mümkün olduğunca farklı yönetmek lazım. Ve kodu geriye çevirmek, veritabanını ya da başka bir şeyi kırmamalı. Çünkü veriniz büyüdüğünüzde başka başka problemlerle karşılaşmanız çok olası.
Cevabın için teşekkür ederim. Burada sormak istediğim github’da revert edilen migration’ın production ortamındaki database’den silinmesi. Bunu manuel olarak migration numaralarını alıp console’dan çalıştırabiliyorum. Benim yapmak istediğimse bunu otomatik olarak hook’larla yapabiliyor muyuz? Veya yapmak yanlış mı? Ruby on rails kullanan şirketler prod ortamına geçmiş hatalı bir migration varsa bunu nasıl geri alıyor gibi sorulara cevap bulmak aslında
Dogrudan revert commit islemi biraz hatalı olabilir. Zira revert ettiginde muhtemelen migration dosyası projeden siliniyor diye varsayiyorum senin durumunda. Haliyle veritabanında olan ancak projede olmayan bir migration olusuyor. CI calisirken de revert sonrasi tetiklenecegini icin neyi silecegini dahi bilemeyecek cunku ortada dosya yok down kismi calistirilacak. Instructionlar olmadan neyin silinecegi belli degil.
Ayrica bence diger bir gorunmeyen problem de diger gelistiriciler (ya da varsa staging vb diger ortamlar). Bu sorunu production icin ci/lambda vb bir yontemle cozsen bile local makinasi bozulan developer manuel cozmek zorunda kalacak (ki sagliksiz ve epey sorunlu).
Eger bir revert islemi yapilacaksa once veritabani eski hale gelmeli diye dusunuyorum. Su makalede son bolumde ‘The revert method’ altinda bir yontem var. Sahsen daha once hic denemedim ancak bir onceki migration’i revert eden yeni bir migration gayet mantikli gorunuyor.
Soyle bir senaryo on goruyorum git historyde;
#1 - Migration iceren original commit (productiona deploy edilmis)
#2 - revert migration iceren commit
#3 - revert commit#1 (dogrudan git revert ile yapilabilir).
Bu hali herkes icin guvenli gorunuyor bana. Ozellikle #2 nolu commit developer sorumlulugunda ancak hem production hem de local makinalar icin en guvenlisi gibi gorunuyor.
