Когда проект растет, количество миграций начинает быть довольно высоким, и, оглядываясь назад, я вижу много миграций, которые можно было бы реорганизовать. Как слияние create_posts и rename_posts_to_responses в create_responses.Рефакторинг БД Миграции в Ruby on Rails
Является ли это плохой привычкой или я должен поощрять рефакторинг миграции?
Вы могли бы, но позже в проекте, вы действительно не должны запускать миграцию полностью, вы должны быть schema:load 'ing, то есть, если вам нужно запустить совершенно новый экземпляр проекта , По моему опыту, вы будете причинять себе больше головной боли, чем что-либо еще.
Выполнение schema:load немного сложно, если вы включили данные в свои миграции (что происходит с лучшими из нас).
Я видел большие проекты, где все миграции заменяются одной миграцией, взятой из schema.rb. Это еще одна причина не использовать миграцию данных и вместо этого поддерживать набор исходных данных.
на мой взгляд, это хорошо, чтобы реорганизовать в процессе развития [хотя я бы отговорить его, особенно при работе в составе команды], но это слишком легко испортить приложений в производстве рефакторинга миграции
После того как вы проверьте переход на исходный элемент управления, я бы рекомендовал не изменять их. Я делаю редкое исключение, если в нем есть ошибка, но это довольно редко (возможно, 1 из 100).
Причина в том, что как только они вышли в дикую природу, некоторые люди, возможно, их запустили. Они записываются как завершенные в db. Если вы измените их и проверите в новой версии, другие люди не смогут воспользоваться этим изменением. Вы можете попросить людей отменить определенные изменения и повторно запустить их, но это побеждает цель автоматизации. Выполняется часто, это становится беспорядком. Лучше оставить в покое.
Когда вы получаете большое количество миграций, оно может начать чувствовать себя неловко. В общем, вы не будете так много работать. Единственное, что мы делаем, это наш сервер интеграции, который катит и воссоздает базу данных для каждого запуска. Поэтому вы можете просто не открывать этот каталог и притворяться, что их там нет.
Существует практика консолидации миграций. Для этого просто скопируйте текущую схему в перенос и удалите все предыдущие миграции. Тогда у вас меньше файлов для управления, и тесты могут работать быстрее. Вам нужно быть осторожным, особенно если у вас есть миграции, которые автоматически запускаются при производстве. Обычно я заменяю перенос, который, как я знаю, каждый запускал с новой схемой. У других людей есть несколько разные способы сделать это.