Как правильно управлять миграциями для сред разработки и разработки?

Question

У нас приличная команда разработчиков с несколькими параллельными проектами, разрабатываемыми в одной строке кода. Иногда мы добавляем миграции, которые можно запускать в среде разработки, но не следует запускать в prod в течение нескольких месяцев из-за графика выпуска этого проекта. Это заставило нас придерживаться исходных пронумерованных миграций Rails, а не временных меток, поскольку мы можем легко перейти к определенному магическому числу и получить все миграции после этого магического числа.

Такое ощущение, что мы все делаем неправильно. У нас все еще есть проблема разработчиков, создающих ту же самую пронумерованную миграцию. Мы не можем просто держать проект на ветке какое-то время, потому что ветвь будет отклоняться от ствола.

Существует ли метод или инструмент, с которым сталкивался кто-либо, который занимается такими проблемами миграции, как этот?

Answer 1

Вы определенно делаете это неправильно;)

Эффективное управление несколькими «целями» требует хорошего vcs.Я бы предложил git или mercurial, так как хорошая поддержка ветвления (и слияния) необходима.

• действительно используйте миграции с метками времени: проблема с дубликатами решена.
• сохраняйте миграции, которые не должны (пока что) перейти на производство в непроизводственной отрасли.вы можете развернуть «master» в производстве и разрабатывать в ветвях компонентов, или вы можете создать «производственную» ветку и разрабатывать в master.В любом случае вы не будете запускать миграции на производство до тех пор, пока вам действительно не понадобится.
• часто объединяйте ветку 'production' с вашими ветвями разработки -> расходящаяся проблема решена.
• если работает только один человекВ ветке темы он может использовать git rebase вместо слияния с производственной веткой, чтобы сохранить историю развития линейной.