Как Вы управляете базами данных во время разработки?
Когда вы получаете запрос, вы можете
var origin = (req.headers.origin || "*");
, чем когда вы должны ответить, переходите к чему-то подобному:
res.writeHead(
206,
{
'Access-Control-Allow-Credentials': true,
'Access-Control-Allow-Origin': origin,
}
);
10 ответов
Вы можете найти мой вопрос Как создать свою базу данных из системы управления версиями полезным.
По сути, эффективное управление общими ресурсами (например, базой данных) сложно. Это сложно, потому что требуется уравновешивать потребности множества людей, включая других разработчиков, тестировщиков, менеджеров проектов и т. Д.
Часто более эффективно предоставить отдельным разработчикам собственную изолированную среду, в которой они могут выполнять разработку и единицу тестирование, не затрагивая других разработчиков или тестировщиков. Однако это не панацея, потому что теперь вам нужно предоставить механизм, чтобы эти несколько отдельных сред синхронизировались друг с другом с течением времени.Вы должны убедиться, что у разработчиков есть разумный способ улавливать изменения друг друга (как данных, так и схемы и кода). Это не обязательно проще. Хорошая практика SCM может помочь, но для ее реализации все же требуется значительный уровень сотрудничества и координации. Более того, предоставление каждому разработчику собственной копии всей среды может привести к расходам на хранение и дополнительным ресурсам администратора баз данных для помощи в управлении и надзоре за этими средами.
Вот несколько идей, которые вам следует рассмотреть:
- Создайте общую общедоступную «доску среды» (она может быть электронной), где разработчики могут легко видеть, какие среды доступны и кто их использует.
- Укажите человека или группу, которым будут принадлежать ресурсы базы данных. Они несут ответственность за отслеживание сред и помощь в разрешении конфликтующих потребностей различных групп (разработчиков, тестировщиков и т. Д.).
- Если позволяют время и бюджет, подумайте о создании среды песочницы для всех ваших разработчиков.
- Если вы еще этого не сделали, подумайте о том, чтобы отделить «игровые зоны» разработчика от ваших сред интеграции, тестирования и приемочного тестирования.
- Убедитесь, что вы управляете версиями критически важных объектов базы данных - особенно тех, которые часто меняются, например триггеров, хранимых процедур и представлений. Вы не хотите потерять работу, если кто-то перезапишет чужие изменения.
Мы используем локальные базы данных разработчиков и одну основную базу данных для интеграционного тестирования. Мы храним сценарии создания в SCM. Один разработчик отвечает за обновление сценариев SQL на основе схемы «золотой мастер». Разработчик может вносить изменения по мере необходимости в свою локальную базу данных, заполняя при необходимости данные из базы данных интеграции, используя процесс импорта, или генерируя данные с помощью инструмента (в нашем случае Red Gate Data Generator). При необходимости разработчики стирают свою локальную копию и могут по мере необходимости обновлять сценарий создания и данные интеграции. Как правило, базы данных используются только для интеграционного тестирования, и мы макетируем их для модульных тестов, чтобы минимизировать объем работы, обеспечивающей синхронизацию.
Я рекомендую вам взглянуть на взгляды Скотта Аллена по этому вопросу. Он написал серию блогов, которые, на мой взгляд, превосходны. Три правила работы с базами данных , Базовая линия , Сценарии изменения , Представления, сохраненные процессы и т. Д. , Ветвление и слияние .
Я использую эти рекомендации более или менее, с личными изменениями, и они работают.
Я бы согласился со всем, что сказал Л.Бушкин в своем ответе. Если вы используете SQL Server, у нас в Red Gate есть решение, которое позволит вам легко обмениваться изменениями между несколькими средами разработки.
http://www.red-gate.com/products/sql_source_control/index.htm
Если существуют проблемы с хранилищем, из-за которых вашему администратору баз данных трудно разрешить множественную разработку В среде Red Gate есть решение для этого. С технологией Red Gate HyperBac вы можете создавать виртуальные базы данных для каждого разработчика. Они выглядят точно так же, как обычные базы данных, но в фоновом режиме общие данные распределяются между различными базами данных. Это позволяет разработчикам иметь свои собственные базы данных, не занимая непрактичный объем дискового пространства на вашем SQL Server.
У нас есть инструмент обслуживания базы данных, который мы используем, который создает / обновляет наши таблицы и наши процессы. у нас есть сервер с актуальной базой данных, заполненной данными.
мы сохраняем локальные базы данных, с которыми можем играть по своему усмотрению, но когда нам нужно вернуться к «базовому уровню», мы получаем резервную копию «мастера» с сервера и восстанавливаем ее локально.
если / когда мы добавляем столбцы / таблицы / процессы, мы обновляем инструмент dbMain maintenance, который хранится в системе управления версиями.
иногда это неприятно, но это работает достаточно хорошо.
Раньше я справлялся с этим несколькими способами.
Один из них - это репозиторий SQL Script, который создает и заполняет базу данных. Это совсем неплохой вариант, и он может синхронизировать все (даже если вы не используете этот метод, вам все равно следует поддерживать эти сценарии, чтобы ваша БД находилась в системе управления версиями).
Другой (который я предпочитаю) имел единственный экземпляр «чистой» базы данных разработчиков на сервере, к которому никто не подключался. Когда разработчикам требовалось обновить свои базы данных для разработчиков, они запускали пакет SSIS, который копировал «чистую» базу данных в их копию для разработчиков. Затем мы могли бы при необходимости изменять наши базы данных разработчиков, не наступая на ноги другим разработчикам.
Что насчет этого подхода:
Поддерживайте отдельное репо для «чистой базы данных». Репо будет файлом sql с таблицей создания / вставки и т. Д.
Используя Rails (я уверен, что его можно адаптировать для любого репозитория git), поддерживайте «чистый db» как подмодуль в приложении. Напишите сценарий (возможно, rake task), который запрашивает локальную базу данных разработчика с операторами SQL.
Чтобы очистить локальную базу данных (и заменить ее новыми данными):
git submodule init
git submodule update
затем
rake dev_db:update ......... (or something like that!)
Я сделал одно из двух. В обоих случаях разработчики, работающие над кодом, который может конфликтовать с другими, запускают свою собственную базу данных локально или получают отдельный экземпляр на сервере базы данных разработчика.
Подобно тому, что рекомендует @tvanfosson, вы храните набор сценариев SQL, которые могут создавать базу данных с нуля, или
На четко определенной, регулярной основе все базы данных разработчика перезаписываются копией производственных данных или с уменьшенной / деидентифицированной копией производственных данных, в зависимости от того, какие данные мы используем.
Если вы используете ORM, например nHibernate, создайте сценарий, который генерирует как схему, так и данные в ЛОКАЛЬНОЙ базе данных разработки ваших разработчиков.
Улучшите этот сценарий во время разработки, чтобы он включал типовые данные.
Перед развертыванием проверьте промежуточную базу данных.
Мы копируем производственную базу данных в базу данных UAT для конечных пользователей. Эта база данных недоступна разработчикам.
Удаление всех таблиц, их повторное создание и введение тестовых данных занимает меньше нескольких секунд.
Если вы используете ORM, который генерирует схему, вам не нужно поддерживать сценарий создания.
Ранее я работал над продуктом, который был связан с хранилищем данных и предназначался для установки на сайтах клиентов по желанию. Следовательно, программное обеспечение знало, как проводить "установку" (в основном, создание необходимой схемы базы данных и внесение статических данных, таких как коды валют/стран и т.д.).
Поскольку у нас была эта информация в самом коде, и поскольку у нас были подключаемые SQL-адаптеры, было очень просто заставить этот код работать с базой данных in-memory (мы использовали HSQL). Поэтому мы проводили большую часть нашей фактической разработки и тестирования производительности на "настоящих" локальных серверах (Oracle или SQL Server), а все модульное тестирование и другие автоматизированные задачи - на специфических для конкретного процесса базах данных в памяти.
Нам очень повезло в этом отношении, что если происходило изменение централизованных статических данных, нам нужно было включить его в часть инструкций по обновлению, поэтому по умолчанию оно хранилось в репозитории SCM, проверялось разработчиками и устанавливалось как часть их обычного рабочего процесса. По размышлении это очень похоже на предложенную вами идею журнала изменений в БД, только немного более формализованную и со специфическим для конкретной области слоем абстракции вокруг нее.
Эта схема работала очень хорошо, потому что любой мог создать полностью рабочую БД с актуальными статическими данными за несколько минут, не наступая никому на пятки. Я не могу сказать, стоит ли это делать, если вам не нужна функциональность установки/обновления, но я бы рассмотрел этот вариант в любом случае, потому что он сделал зависимость от базы данных совершенно безболезненной.