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.