Який хороший спосіб перенести зміни БД із Development до QA у виробничі середовища? В даний час ми:

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

Проблема в цьому полягає в тому, що воно дуже ручне. Він покладається на те, що розробник запам'ятовує приєднати sql або рецензент, який його вловлює, якщо розробник забуде. Іноді в кінцевому підсумку це випробувач або QA-розгортач, який виявляє проблему.

Вторинна проблема полягає в тому, що іноді вам потрібно вручну координувати зміни, якщо дві окремі завдання змінюють один і той же об’єкт бази даних. Це може бути саме так, але все ж здається, що має бути якийсь автоматизований спосіб "позначати" ці питання чи щось таке.

Наше налаштування: Наш магазин розробників наповнений розробниками з великим досвідом роботи з БД. Наші проекти дуже орієнтовані на БД. Ми в основному .NET і MS SQL магазин. В даний час ми використовуємо MS TFS Work items для відстеження нашої роботи. Це зручно для змін коду, оскільки він пов'язує набори змін з робочими елементами, щоб я міг точно дізнатися, які зміни мені потрібно включити під час переходу до середовищ якості та виробництва. Зараз ми не використовуємо проект БД, але в майбутньому може перейти до цього (можливо, це є частиною відповіді).

Я дуже звик до моєї системи управління джерелами, піклуючись про такі речі для мене, і хотів би мати те саме, що і для мого SQL.

У середовищі VS я завжди використовував проекти баз даних для реалізації сценаріїв оновлення. Я, як правило, використовую для своїх сценаріїв неімаціональні імена, такі як "DatabaseUpdate17.sql" або "PriceUpdateFebruary2010.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 Ws .

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

Я включаю оператор вставки для реєстрації початку виправлення, а також кінця патча. Події, що відбуваються поза патчами - це речі, на які слід звернути увагу.

Наприклад, вставка "start 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

Більш рання версія, розміщена раніше на серверній помилці .

У середовищі, сумісному з SOX та PCI-DSS, ви ніколи не матимете доступу до виробничих серверів. Тому сценарії потрібно заздалегідь зрозуміти та виконувати. Коментарі вгорі скриптів оновлення містять списки нових таблиць, збережені програми, функції тощо, а також списки модифікованих таблиць, збережені програми, функції тощо. Якщо дані змінюються, поясніть, що змінюється та чому.

Вторинна проблема полягає в тому, що іноді вам потрібно вручну координувати зміни, якщо дві окремі завдання змінюють один і той же об’єкт бази даних. Це може бути саме так, але все ж здається, що має бути якийсь автоматизований спосіб "позначати" ці питання чи щось таке.

Я ніколи не натрапляв на інструмент, який дозволяє нам автоматично відстежувати це. Попередні роботодавці застосовували принцип "власника бази даних" - однієї і єдиної людини, яка особисто відповідає за базою даних. Ця людина не буде єдиним розробником, який працює проти цієї бази даних, але, скоріше, всі зміни повинні пройти через них. Це досить добре попрацювало, щоб уникнути змін та нанесення шкоди один одному.

Ви подивилися на керування джерелами SQL? Ви можете використовувати його для підключення свого SQL-сервера до TFS / SVN / Vault або VSS - http://www.red-gate.com/products/sql-development/sql-source-control/

Ще одне рішення - використовувати щось на зразок PowerDesigner, ERWin тощо для проектування та управління змінами у вашій базі даних.

Ми починаємо переходити до політики, де бази даних моделюються в PowerDesigner. Всі зміни структури / коду бази даних здійснюються в моделі, перевіряються в керуванні джерелами, а потім сценарії зміни генеруються з моделей для здійснення змін у базі даних. Ці сценарії зміни також зареєстровані у контролі джерела. Великі зміни ретельно перевіряються, і PowerDesigner робить це дуже просто, використовуючи вбудовані функції.

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

(Я жодним чином не пов’язаний із Sybase, який розробив PowerDesigner - просто думав, що кину це туди).

Привид DB

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

Переваги

1. Усі об'єкти у вашій базі даних зберігаються як сценарії в контролі джерел.
2. Ви також можете скриптувати "статичні дані" (дані таблиці пошуку).
3. Ви можете оновити керування джерелами вручну або за допомогою створення сценарію БД "модель".
4. Ви можете створити базу даних (швидко) зі скриптів у керуванні джерелами (включаючи статичні дані).
5. Ви можете розгорнути зміни в екземплярах бази даних, включаючи будь-які виробничі екземпляри:
   • Ви можете порівняти "збір бази даних" (створений із скриптів) з існуючою базою даних та створити сценарій зміни.
   • Ви можете направити DB Ghost для автоматичної синхронізації змін між двома екземплярами бази даних, наприклад, зібраною базою даних та виробничою базою даних.

[4] особливо зручний для внесення змін на місцевому рівні або створення окремих примірників для різних середовищ. Насправді це так просто, що я створюю окрему базу даних для кожної функції або помилки, над якою працюю, що впливає на базу даних.

Деталі

Основна перевага його використання над підтримкою явних скриптів змін або міграції полягає в тому, що в основному вам не потрібно підтримувати явні сценарії змін або міграції - ви здебільшого можете підтримувати лише "поточну версію" вашої бази даних. Одним із дратівливих аспектів управління сценаріями міграції є те, що немає простого способу побачити, наприклад, список стовпців таблиці (на основі сценаріїв міграції). Звичайно, деякі зміни потрібно внести як явні міграції, але вони досить прості для обробки як окремі сценарії.

Особливо приємним наслідком того, що можна керувати базами даних (набором) скриптів, а також мати можливість швидко створювати нові екземпляри, - тестування важливого коду бази даних дуже просто (і дуже цікаво теж). Я використовую tSQLt для тестування одиниць.

Мені б хотілося, щоб був подібний інструмент для інших СУБД.

Я знаю, це здається непосильним для більшості DBA:

Чи планували ви використовувати Ruby on Rails для відстеження змін у Базі даних (і лише змін у БД). Вам не потрібно запускати будь-яку програму або писати будь-який рубіновий код і т. Д. Але я знайшов стиль міграції (так вони називають) досить корисний: http://guides.rubyonrails.org/migrations.html

Також підтримується сервер Sql, можливо, вам доведеться використовувати JRuby + JDBC.