Пожалуйста, предложите лучший способ организовать базы данных разработки

Question

В настоящее время я работаю над веб-проектом, в котором все мы подключаемся к одной базе данных разработки.

И, как и другие централизованные системы, во времени эта база данных оказывается единственной точкой отказа.

Если один из разработчиков небрежно сбрасывает некоторые грязные данные в базу данных, все остальные разработчики страдают от этого.

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

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

Пожалуйста, дайте мне несколько предложений.

Answer 1

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

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

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

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

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

Answer 2

В моих проектах база данных разработки всегда находится на локальной машине разработчиков. Мы используем SQL Server Developer Edition или SQL Server Express. Мы сохраняем SQL-скрипт для создания проверенного в БД в репозитории исходного кода. Любой, кто нуждается в воссоздании своей локальной БД, может это использовать. Один член команды отвечает за поддержание сценария SQL, и любые изменения в базе данных идут к нему сначала (как правило, SQL-скрипты). Он получает самую последнюю версию сценария из SCM, обновляет свою локальную копию и генерирует обновленный скрипт создания, который заменяет скрипт в SCM. В то же время сопровождающие изменения кода проверяются в SCM, чтобы код и БД были синхронизированы. Все остальные синхронизируются с этой версией.

Это дает людям свободу работать параллельно и при необходимости изменять схему, включая экспериментальные изменения, которые могут быть отброшены. Мы также используем локальную БД в качестве источника для фиктивных данных для локального тестирования веб-приложения, а не для модульного тестирования, мы обычно издеваемся над этим DB, но тестирование на интеграцию и UI. Сохранение локальных баз данных позволяет каждому разработчику настроить его для их тестирования по мере необходимости без какой-либо координации с другими.

Следует также упомянуть, что мы используем Red Gate's SQL Compare для распространения только изменений вокруг, как только локальная БД координатора находится в официальной проверенной версии.Это альтернатива отказу и воссозданию БД и намного лучше сохраняет существующие данные. В зависимости от изменений БД это может быть тривиальная или несколько сложная операция. Мы всегда используем его для обновления контрольных и тестовых и производственных БД, если изменения настолько тривиальны, что их можно сделать вручную (без ошибок).

Answer 3

Что касается личной локальной базы данных SQLite. Многие разработчики Rails довольны этим решением.

Answer 4

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

Мы создали одну виртуальную машину для каждой поддерживаемой нами базы данных (oracle, db2, mssql, mysql). Теперь каждый разработчик может просто скопировать и запустить виртуальную машину локально без необходимости ее установки.

Answer 5

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

До тех пор, пока DDL и тестовые данные находятся в управлении версиями, каждый работает против одной и той же базы данных. Еще одно преимущество заключается в том, что если я работаю над функцией, требующей изменения БД, каждый получает как код, так и тестовые данные DDL +, необходимые для этого изменения.

В сфере Java DbUnit в нашем случае вместе с плагином Hibernate Maven очень полезен для этого. Разумеется, простое домашнее решение может преуспеть.

Answer 6

Мы используем тот же базовый процесс, который описаны здесь другими людьми, с некоторыми существенными изменениями. Каждый разработчик обычно имеет свой собственный экземпляр db, и мы управляем им с помощью скриптов изменений. Вот подробности:

1. У нас есть базовый сценарий базы данных для создания начального дБ. Это включает создание таблицы в db, которую мы используем для отслеживания версии схемы db.
2. Все СП, представления и функции списаны в отдельные файлы.
3. Если вам нужно внести изменения в схему, вы напишите сценарий, который изменит это. Он должен проверить таблицу версий схемы, чтобы убедиться, что db находится в правильной версии, чтобы применить это изменение схемы. Такие вещи, как инструменты Red-Gate, очень помогают писать эти скрипты, но они не являются существенными.
4. У нас есть небольшая программа, которую мы написали, которая автоматически запускает все эти сценарии в отношении базы данных. Он проверит текущую версию схемы db и запустит новые сценарии изменения схемы. Он всегда будет запускать все сценариев SP, просмотра и т. Д.

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