Comments 16
А зачем это нужно, когда есть миграции?
Когда есть — не нужно.
А все же, чем миграции вам не подошли?
Я не могу сказать, что они не подошли. Просто в работе использую (и попадаются) множество инструментов и языков. Далеко не всегда нужно прикручивать ORM и конкретные Framework'и, обычно это означает кучу зависимостей даже для мелкого проекта.
Вот чем хорош Git, все основывается на файлах, любой другой инструмент, умеющий писать в файл — может его использовать вне зависимости от структуры проекта или его размера. Причем Git не вмешивается во внутренности проекта и не заставляет нас быть чем-то.
Мое решение — тоже такого рода решение для MySQL без привязки к инструменту/ORM/фреймворку. Вне зависимости от нашей структуры БД и клиентов, которыми мы пользуемся при ее создании — оно будет работать.
Вот чем хорош Git, все основывается на файлах, любой другой инструмент, умеющий писать в файл — может его использовать вне зависимости от структуры проекта или его размера. Причем Git не вмешивается во внутренности проекта и не заставляет нас быть чем-то.
Мое решение — тоже такого рода решение для MySQL без привязки к инструменту/ORM/фреймворку. Вне зависимости от нашей структуры БД и клиентов, которыми мы пользуемся при ее создании — оно будет работать.
А что мешает оформить миграции в виде голых SQL-файлов, без привязки к ORM или фреймворку?
Коммитить их в git-репозиторий вручную. Для накатывания использовать специальный скрипт (коих существует великое множество, на любой вкус).
Коммитить их в git-репозиторий вручную. Для накатывания использовать специальный скрипт (коих существует великое множество, на любой вкус).
Так, вот смотрите, как это сделано в моем решении
1. Мы в любом mysql-редакторе создаем или меняем структуру базы данных.
2. Автоматически ведется лог изменений, файлы которого попадают в Git-папку с кодом проекта (незакоммитчены, но готовы к этому вместе с файлами проекта).
3. Вместе с новым коммитом в репозитарий попадают также изменения БД (так же, как и изменения кода).
4. На production автоматически вместе с этой версией кода — получаем версию базы данных.
На всем промежутке разработки структуры БД на dev-сервере мы не задумываемся о том, как она будет синхронизирована на production-сервере — все происходит автоматически.
Если вы знаете подобное решение — расскажите, пожалуйста, я не нашла.
1. Мы в любом mysql-редакторе создаем или меняем структуру базы данных.
2. Автоматически ведется лог изменений, файлы которого попадают в Git-папку с кодом проекта (незакоммитчены, но готовы к этому вместе с файлами проекта).
3. Вместе с новым коммитом в репозитарий попадают также изменения БД (так же, как и изменения кода).
4. На production автоматически вместе с этой версией кода — получаем версию базы данных.
На всем промежутке разработки структуры БД на dev-сервере мы не задумываемся о том, как она будет синхронизирована на production-сервере — все происходит автоматически.
Если вы знаете подобное решение — расскажите, пожалуйста, я не нашла.
Ну почти так, собственно, и делают. По сути, в приведенном решении миграции создаются автоматически. Ну еще накатываются они на продакшн автоматом после попадания в гит (что по мне очень сомнительная фишка).
Обычно миграции создают руками (часто это тупо файлики с SQL, прямо как в приведенном решении). Вроде лишняя работа, да и SQL надо знать, зато меньше ошибок накосячить, проще ревьювить, мерджить миграции от нескольких разработчиков и т.п.
А для накатывания миграций есть много готовых скриптов. Которые и логи свои ведут, и не позволят накатить файлик дважды по ошибке, и много еще чего сделают полезного.
Советую посмотреть на liquibase.
Обычно миграции создают руками (часто это тупо файлики с SQL, прямо как в приведенном решении). Вроде лишняя работа, да и SQL надо знать, зато меньше ошибок накосячить, проще ревьювить, мерджить миграции от нескольких разработчиков и т.п.
А для накатывания миграций есть много готовых скриптов. Которые и логи свои ведут, и не позволят накатить файлик дважды по ошибке, и много еще чего сделают полезного.
Советую посмотреть на liquibase.
Обычно миграции создают руками (часто это тупо файлики с SQL, прямо как в приведенном решении). Вроде лишняя работа, да и SQL надо знать, зато меньше ошибок накосячить, проще ревьювить, мерджить миграции от нескольких разработчиков и т.п.
Ну именно эту часть мое решение и позволяет автоматизировать и не «косячить» с SQL, а пользоваться любыми удобными редакторами. Разве автоматизация это плохо?
Не надо прикручивать ORM. Возьмите просто Schema Manager (http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/schema-manager.html)
Позволяет задать спецификацию для структур таблиц, после сравнить её с реальной структурой и вычислить разность в виде массива sql-выражений
Позволяет задать спецификацию для структур таблиц, после сравнить её с реальной структурой и вычислить разность в виде массива sql-выражений
… скрипт отслеживающий появление новых файлов…Выглядит, как задачка для хука
… при обновлении git-репозитария на production-сервере вместе с кодом, мы изменяем базу данных...
post-checkout. По крайней мере, он не висит где-то в фоне.
Отличная идея, на мой взгляд, допилить скрипт и думаю получится наконец то базу битрикса нормально синхронизировать между dev и prod серверами.
Просто там нужно будет смотреть не только изменение структуры таблиц, но и данных в куче таблиц, но судя по всему ничего невозможного нет.
Просто там нужно будет смотреть не только изменение структуры таблиц, но и данных в куче таблиц, но судя по всему ничего невозможного нет.
А еще есть binary logs. Но включать general-log на более-менее загруженном проекте — самоубийство.
Еще если нужно просто держать актуальные версии структуры MySQL, то можно взглянуть на mysql-php-migrations.
Sign up to leave a comment.
Синхронизация структуры MySQL + Git