Каков хороший способ перенести изменения БД из среды разработки в систему контроля качества в рабочую среду? В настоящее время мы:

1. Сценарий изменения в файле SQL и присоединить его к рабочему элементу TFS.
2. Работа рецензируется
3. Когда работа готова к тестированию, SQL запускается на QA.
4. Работа проверена QA
5. Когда работа готова к производству, SQL запускается на производственных базах данных.

Проблема в том, что он очень ручной. Он полагается на то, что разработчик не забудет присоединить sql или рецензент, который поймает его, если разработчик забудет. Иногда он оказывается тестером или разработчиком QA, который обнаруживает проблему.

Вторая проблема заключается в том, что вам иногда приходится вручную координировать изменения, если две отдельные задачи изменяют один и тот же объект базы данных. Может быть, так оно и есть, но все же кажется, что должен быть какой-то автоматизированный способ «пометки» этих проблем или что-то в этом роде.

Наша установка: наш цех разработки полон разработчиков с большим опытом работы с БД. Наши проекты ориентированы на БД. В основном мы являемся магазином .NET и MS SQL. В настоящее время мы используем рабочие элементы MS TFS для отслеживания нашей работы. Это удобно для изменений кода, потому что он связывает наборы изменений с рабочими элементами, чтобы я мог точно узнать, какие изменения мне нужно включить при переходе на среды QA и Production. В настоящее время мы не используем проект БД, но можем переключиться на него в будущем (возможно, это часть ответа).

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

В среде VS я всегда использовал проекты баз данных для реализации сценариев обновления. Я склонен использовать для своих сценариев неимоверные имена, такие как «DatabaseUpdate17.sql» или «PriceUpdateFeb February2010.sql». Имея их в качестве проектов баз данных, я могу связать их с задачами Team Server, ошибками (и, если мы проверяли код, с ними тоже). Я также включаю в каждую базу данных (на которую у меня есть полномочия) таблицу специально для сбора изменений в схеме.

CREATE TABLE [dbo].[AuditDDL](
    [EventID] [int] IDENTITY(1,1) PRIMARY KEY NOT NULL,
    [EventData] [xml] NULL,                    -- what did they do
    [EventUser] varchar(100) NOT NULL,         -- who did it
    [EventTime] [datetime] DEFAULT (getdate()) -- when did they do it
    )
GO

Ну, это заботится о 3 из 6 Вт .

CREATE TRIGGER [trgAuditDDL]
ON DATABASE 
FOR DDL_DATABASE_LEVEL_EVENTS 
AS
INSERT INTO AuditDDL(EventData, EventUser)
SELECT EVENTDATA(), original_login()
GO

Я включаю оператор вставки для регистрации начала патча, а также конца патча. События, происходящие вне патчей - это то, на что стоит обратить внимание.

Например, вставка «begin patch» для «patch 17» будет выглядеть так:

INSERT INTO [dbo].[AuditDDL]
           ([EventData]
           ,[EventUser])
     VALUES
           ('<EVENT_INSTANCE><EventType>BEGIN PATCH 17</EventType></EVENT_INSTANCE>'
           ,ORIGINAL_LOGIN())
GO

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

DELETE FROM AuditDDL
WHERE [EventData].exist('/EVENT_INSTANCE/EventType/text()[fn:contains(.,"ALTER_INDEX")]') =1
GO

DELETE FROM AuditDDL
WHERE [EventData].exist('/EVENT_INSTANCE/EventType/text()[fn:contains(.,"UPDATE_STATISTICS")]') =1
GO

Более ранняя версия ранее размещалась на сервере Fault .

В среде, совместимой с SOX и PCI-DSS, у вас никогда не будет доступа к рабочим серверам. Поэтому сценарии должны быть ясны и выполнены заранее. Комментарии в верхней части сценариев обновления включают списки новых таблиц, хранимых процедур, функций и т. Д., А также списки модифицированных таблиц, хранимых процедур, функций и т. Д. Если данные изменяются, объясните, что и почему было изменено.

Вторая проблема заключается в том, что вам иногда приходится вручную координировать изменения, если две отдельные задачи изменяют один и тот же объект базы данных. Может быть, так оно и есть, но все же кажется, что должен быть какой-то автоматизированный способ «пометки» этих проблем или что-то в этом роде.

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

Вы смотрели на SQL Source Control? Вы можете использовать его для подключения вашего SQL Server к TFS / SVN / Vault или VSS - http://www.red-gate.com/products/sql-development/sql-source-control/

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

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

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

(Я никоим образом не связан с Sybase, который разработал PowerDesigner - просто подумал, что я добавлю это туда).

БД Призрак

DB Ghost - мой любимый инструмент для управления базами данных.

Выгоды

1. Все объекты в вашей базе данных хранятся в виде скриптов в системе контроля версий.
2. Вы также можете написать «статические данные» (данные таблицы поиска).
3. Вы можете обновить управление исходным кодом вручную или с помощью сценария базы данных разработки «модели».
4. Вы можете построить базу данных (быстро) из сценариев в системе контроля версий (включая статические данные).
5. Вы можете развернуть изменения в экземплярах базы данных, включая любые производственные экземпляры:
   • Вы можете сравнить «базу данных сборки» (созданную из сценариев) с существующей базой данных и сгенерировать сценарий изменения.
   • Вы можете настроить DB Ghost на автоматическую синхронизацию изменений между двумя экземплярами базы данных, например, базой данных сборки и вашей производственной базой данных.

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

Детали

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

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

Я только хотел бы, чтобы был подобный инструмент для других СУБД.

Я знаю, это звучит излишне для большинства администраторов баз данных:

Рассматривали ли вы использование Ruby on Rails для отслеживания изменений в базе данных (и только изменений в базе данных). Вам не нужно запускать какое-либо приложение или писать какой-либо код ruby ​​и т. Д. Но я обнаружил, что стиль миграции (так его называют) весьма полезен: http://guides.rubyonrails.org/migrations.html

Сервер Sql также поддерживается, вам, возможно, придется использовать JRuby + JDBC.