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

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

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

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

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

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

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

4 голоса | спросил satoru 6 Jpm1000000pmWed, 06 Jan 2010 15:59:53 +030010 2010, 15:59:53

6 ответов


0

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

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

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

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

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

ответил DOK 6 Jpm1000000pmWed, 06 Jan 2010 16:08:49 +030010 2010, 16:08:49
0

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

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

ответил tangens 6 Jpm1000000pmWed, 06 Jan 2010 16:14:12 +030010 2010, 16:14:12
0

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

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

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

ответил Confusion 6 Jpm1000000pmWed, 06 Jan 2010 16:19:35 +030010 2010, 16:19:35
0

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

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

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

ответил tvanfosson 6 Jpm1000000pmWed, 06 Jan 2010 16:09:11 +030010 2010, 16:09:11
0

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

ответил zzeroo 6 Jpm1000000pmWed, 06 Jan 2010 16:11:16 +030010 2010, 16:11:16
0

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

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

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

ответил jeffesp 6 Jpm1000000pmWed, 06 Jan 2010 16:30:45 +030010 2010, 16:30:45

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132