Как я могу поддерживать порядок рефакторинга, используя программное обеспечение для рефакторинга базы данных?

Я пытался использовать либо Liquibase или DBDeploy. Меня больше тянет к Liquibase из-за не-SQL интерфейса (IE я могу просто использовать наборы изменений JSON или Yaml). Однако у меня есть проблема с обоими этими программами.

Liquibase Workflow

  1. Я создаю основной журнал изменений. Все, что он делает, это includeAll папка, которая содержит небольшие файлы с небольшими изменениями внутри.
  2. Затем я создаю наборы изменений и добавляю к ним префикс с числом (например, отметка времени или простое целое число, например 1, 2 и т. Д.).

DBDeploy Рабочий процесс

  1. Я просто начинаю создавать дельта-файлы sql с префиксом той же стратегии, что и номер 2 выше.

Эта проблема

Ну, проблема настолько тривиальна, что я чувствую себя глупо, когда спрашиваю об этом, но здесь все кончено. Рассмотрим этот сценарий:

  1. Я делаю ветку для работы над своей функцией, скажем, добавляя заказы в систему.
  2. Мой коллега Боб создает собственную ветку для добавления продуктов в систему.
  3. Когда приходит время слияния, неизвестно, чьи наборы изменений или дельта sqls будут выполняться первыми. Это может сломать базу данных.

Разве это ни с кем не случается? Если да, то как решить эту проблему на земле PHP?

Благодарю.

Источник

2 ответа

Решение

Я использовал несколько различных структур миграции - Liquibase, Rails и что-то из мира C# под названием Tarantino. Каждый использовал похожую стратегию, где изменения были записаны в отдельных файлах. Каждый был в небольшой команде (<= 5 разработчиков).

Rails - самый догматичный способ именования файлов, и именно здесь у меня было больше конфликтов из-за веток. Большинство этих конфликтов были основаны на именах, а не на логических конфликтах в базе данных.

В проектах, использующих Liquibase, мы использовали шаблон master/include, а разработчики делали свою работу над ветвями. Поскольку имена файлов имели 3-значные порядковые номера плюс краткое описание (например, 009-add-customer0index.xml), у нас не было конфликтов имен. Мы избегали конфликтов на уровне базы данных, главным образом, просто общаясь друг с другом - ежедневные перестановки и т. Д.

У нас был похожий опыт использования Tarantino, хотя он просто использует каталог, полный файлов для своих миграций. Как и в случае с Liquibase, мы приняли соглашение об именах, которое содержало все в порядке. Даже если у двух наборов изменений было одно и то же число, они имели бы разные имена, и в 99,9% случаев порядок этих двух наборов изменений не зависел друг от друга.

Просто для назначения данных, проект, который использовал Tarantino, выровнялся с приблизительно 400 ревизиями.

Источник

(Я знаю только жидкостьбазу - поэтому мой ответ действителен только для ликвидазы)

Как includeAll Документ утверждает, что файлы будут работать в алфавитном порядке. Поэтому я ожидаю, что ваша нумерация должна быть достаточной, чтобы файлы были в правильном порядке. Однако вам все равно придется синхронизировать эти числа между вами и Бобом, чтобы выяснить, что должно выполняться в первую очередь.

Мы не используем includeAll хоть. Мы включаем файлы в основной список изменений вручную. Поэтому любой, кто хочет изменить базу данных, должен позаботиться о включении этого в основной список изменений. Если есть два изменения, разработчик, который приходит последним, должен включить / объединить свои изменения в нужном месте в главном журнале изменений.

EDITED - чтобы объяснить механизм включения, который мы используем

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

Только когда разработка версии, над которой мы работаем (или спринт), завершена. Тогда мы действительно позволяем изменениям работать и позволять им изменять производительную базу данных.

Затем этот цикл повторяется снова и снова.

Таким образом, только жидкие базы отслеживают только окончательные изменения в БД, а не все попытки, которые могут иметь место во время разработки.

В процессе разработки вы можете несколько раз менять таблицу, потому что вы пробуете разные вещи. Вы добавляете столбец, затем понимаете, что все это не будет работать, поэтому вы снова удаляете столбец и добавляете еще один. Почему вы хотите иметь все эти изменения в databasechangelog? Тогда он будет заполнен ненужными вещами - как вы и боялись.

Надеюсь, это прояснит ситуацию. Но, в конце концов, у вас может быть совершенно другой подход к разработке. Так что не стесняйтесь использовать ликвидазу так, как вам это нужно.

Нет причин заполнять таблицу databasechangelog всеми идеями в процессе разработки. Только когда мы закончили с разработкой и выпуском версии

Источник
Другие вопросы по тегам