Блог

У меня есть некоторая таблица и записи в базе данных, которые я использую для ручного тестирования моего (PHP) кода. Предположим, я хотел бы поделиться этими записями и структурой таблицы (например, с другими разработчиками); если какая-то модель изменится или будет добавлена новая таблица, все узнают.

Как вы интегрируете эту потребность в свой процесс разработки? Моя идея заключается в том, что при каждой фиксации сбрасывается база данных в файл и также фиксируется этот файл после того, как скрипт удостоверяется, что он изменен. При обновлении также обновите этот файл и перезагрузите другую базу данных разработки. Это может быть возможно с помощью external tool функции eclipse, но я чувствую, что это немного халтурно.

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

Существует множество методологий для обработки тестовых данных, но мы используем следующий процесс:

• Поддерживайте проект (Visual Studio поддерживает проекты баз данных) или, по крайней мере, структуру папок с вашими сценариями базы данных в нем
• Создайте инструмент, способный извлекать последние скрипты и создавать из них базу данных
• Экспортируйте свои данные в некоторый формат, который может быть выполнен после запуска сценариев (инструкции INSERT или что-то еще)

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

Альтернативой этому было бы ведение базы данных разработки для всех разработчиков, которая у нас также есть. Таким образом, у вас есть одна «золотая» копия базы данных разработки с последними изменениями схемы и тестовыми данными.

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

Поскольку тестовые данные обычно не изменяются при каждой фиксации, а обновляются только для размещения новых тестов или схемы, это делается вручную, в основном для предотвращения сброса данных, которые изменены в результате тестирования (с использованием тестовых данных). Однако вы могли бы написать сценарий для этого дампа или создать целевой объект в своем программном обеспечении для сборки.

Мы делаем это с помощью ant и файла слияния. Файл слияния — это обновление файла данных в SQL (инструкции alter table, INSERT, UPDATE и тому подобное). Цель ant инициализируется последней версией тестовых данных, выполняет файл слияния с ними и сбрасывает новые данные. Таким образом, всегда будет ясно, какие были изменения.

SQL Data Compare Pro работает параллельно SQL Compare, позволяя создавать сценарии для статических данных, а также схемы, которые хранятся в системе управления версиями. Это делается путем сохранения SQL-файлов с инструкциями DML (INSERT). SQL Data Compare Pro также может выполнять развертывание из этих самых файлов в базу данных, а также создавать сценарии для файлов.

http://www.red-gate.com/products/SQL_Data_Compare/index.htm

Отказ от ответственности: я работаю менеджером по продуктам в Red Gate для инструментов сравнения SQL.