Як слід створити свою базу даних з управління джерелами?

У вікі спільноти SO було проведено певну дискусію щодо того, чи слід керувати версіями об'єктів бази даних. Тим НЕ менше, я не бачив багато дискусій про передовий практиці для створення процесу збирання-автоматизації для об'єктів бази даних.

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

Мені хотілося б почути деякі ідеї спільноти про те, які практики були ефективними в реальному світі.

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

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

1. Чи слід будувати як тестове, так і виробниче середовище з управління джерелами?
   
   • Чи повинні обидва бути побудовані за допомогою автоматизації - чи виробництво має будуватися шляхом копіювання об'єктів із стабільного, завершеного тестового середовища?
   • Як ви вирішуєте потенційні відмінності між тестовим та виробничим середовищем в сценаріях розгортання?
   • Як ви перевіряєте, що сценарії розгортання працюватимуть так само ефективно, як і в тесті?
2. Які типи об’єктів слід контролювати версії?
   • Просто код (процедури, пакети, тригери, java тощо)?
   • Індекси?
   • Обмеження?
   • Визначення таблиці?
   • Сценарії зміни таблиці? (наприклад, сценарії ALTER)
   • Все?
3. Які типи об'єктів не повинні контролюватися версіями?
   • Послідовності?
   • Гранти?
   • Облікові записи користувачів?
4. Як слід організувати об’єкти бази даних у вашому сховищі SCM?
   • Як ви маєте справу з разовими речами, такими як скрипти перетворення або сценарії ALTER?
   • Як ви маєте справу з вилученням об'єктів із бази даних?
   • Хто повинен відповідати за просування об’єктів від розробки до рівня тесту?
   • Як ви координуєте зміни від декількох розробників?
   • Як ви маєте справу з розгалуженням для об’єктів бази даних, які використовуються у кількох системах?
5. Які винятки, якщо такі є, можуть бути прийнятними для цього процесу?
   • Питання безпеки?
   • Дані, що стосуються деедентифікації?
   • Сценарії, які неможливо повністю автоматизувати?
6. Як ви можете зробити процес стійким і примусовим?
   • Помилка розробника?
   • До несподіваних екологічних проблем?
   • Для відновлення після катастроф?
7. Як ви переконуєте осіб, які приймають рішення, що переваги DB-SCM справді виправдовують витрати?
   • Анекдотичні докази?
   • Промислові дослідження?
   • Рекомендації щодо найкращої практики в галузі?
   • Звернення до визнаних органів влади?
   • Аналіз витрат / вигод?
8. Хто повинен "володіти" об'єктами бази даних у цій моделі?
   • Розробники?
   • DBA?
   • Аналітики даних?
   • Більше одного?

Ось кілька відповідей на ваші запитання:

1. Чи слід будувати як тестове, так і виробниче середовище з управління джерелами? ТАК
   • Чи повинні обидва бути побудовані за допомогою автоматизації - чи виробництво має будуватися шляхом копіювання об'єктів із стабільного, завершеного тестового середовища?
   • Автоматизація для обох. НЕ копіюйте дані між середовищами
   • Як ви вирішуєте потенційні відмінності між тестовим та виробничим середовищем в сценаріях розгортання?
   • Використовуйте шаблони, щоб фактично ви створювали різні набори сценаріїв для кожного середовища (наприклад, посилання на зовнішні системи, пов'язані бази даних тощо)
   • Як ви перевіряєте, що сценарії розгортання працюватимуть так само ефективно, як і в тесті?
   • Ви випробовуєте їх у виробничому середовищі: тестова розгортання на точній копії виробничого середовища (база даних та потенційно інші системи)
2. Які типи об’єктів слід контролювати версії?
   • Просто код (процедури, пакети, тригери, java тощо)?
   • Індекси?
   • Обмеження?
   • Визначення таблиці?
   • Сценарії зміни таблиці? (наприклад, сценарії ALTER)
   • Все?
   • Все, і:
     • Не забувайте статичні дані (списки пошуку тощо), тому вам не потрібно копіювати БІЛЬКІ дані між середовищами
     • Зберігайте лише поточну версію скриптів бази даних (звичайно, керована версія) та
     • Зберігайте сценарії ALTER: 1 BIG-скрипт (або каталог скриптів з іменем "00"
3. Які типи об'єктів не повинні контролюватися версіями?
   • Послідовності?
   • Гранти?
   • Облікові записи користувачів?
   • див. 2. Якщо ваші користувачі / ролі (або технічні імена користувачів) відрізняються між середовищами, ви все одно можете їх скриптувати за допомогою шаблонів (див. 1.)
4. Як слід організувати об’єкти бази даних у вашому сховищі SCM?
   • Як ви маєте справу з разовими речами, такими як скрипти перетворення або сценарії ALTER?
   • див. 2.
   • Як ви маєте справу з вилученням об'єктів із бази даних?
   • видалено з БД, видалено з ствола / наконечника управління джерелом
   • Хто повинен відповідати за просування об’єктів від розробки до рівня тесту?
   • розклад / тест / графік випуску
   • Як ви координуєте зміни від декількох розробників?
   • Спробуйте НЕ створювати окрему базу даних для кожного розробника. ви використовуєте джерело-контроль, правда? в цьому випадку розробники змінюють базу даних та сценарії реєстрації. щоб бути повністю безпечним, заново створіть базу даних зі скриптів під час нічного збирання
   • Як ви маєте справу з розгалуженням для об’єктів бази даних, які використовуються у кількох системах?
   • важкий: намагайтеся уникати будь-якою ціною.
5. Які винятки, якщо такі є, можуть бути прийнятними для цього процесу?
   • Питання безпеки?
   • не зберігайте паролі для тесту / продукту. ви можете дозволити це для розробників, особливо якщо ви автоматизували щоденні / нічні відновлення БД
   • Дані, що стосуються деедентифікації?
   • Сценарії, які неможливо повністю автоматизувати?
   • документуйте і зберігайте разом із інформацією про випуск / сценарієм ALTER
6. Як ви можете зробити процес стійким і примусовим?
   • Помилка розробника?
   • перевіряється щоденним складанням з нуля та порівнюють результати з поступовим оновленням (від версії А до В за допомогою ALTER). порівняйте як отриману схему, так і статичні дані
   • До несподіваних екологічних проблем?
   • використовувати контроль версій та резервні копії
   • порівняйте схему бази даних PROD з тією, яку ви вважаєте, що це таке, особливо перед розгортанням. SuperDuperCool DBA може виправити помилку, якої ніколи не було у вашій системі квитків :)
   • Для відновлення після катастроф?
7. Як ви переконуєте осіб, які приймають рішення, що переваги DB-SCM справді виправдовують витрати?
   • Анекдотичні докази?
   • Промислові дослідження?
   • Рекомендації щодо найкращої практики в галузі?
   • Звернення до визнаних органів влади?
   • Аналіз витрат / вигод?
   • якщо розробники та DBA погоджуються, вам не потрібно нікого переконувати, я думаю (якщо тільки вам не потрібні гроші, щоб придбати таке програмне забезпечення, як dbGhost для MSSQL)
8. Хто повинен "володіти" об'єктами бази даних у цій моделі?
   • Розробники?
   • DBA?
   • Аналітики даних?
   • Більше одного?
   • Зазвичай модель DBA затверджує модель (перед реєстрацією або після її розгляду в коді). Вони безумовно володіють об'єктами, пов'язаними з продуктивністю. Але в цілому команда володіє ним [і роботодавець, звичайно :)]

Я ставлюся до SQL як вихідний код, коли це можливо

Якщо я можу записати його в сумісний з SQL стандарт, тоді він, як правило, зберігається у файлі в моєму керуванні джерелом. У файлі буде максимально визначено такі, як SP, Table CREATE.

Я також включаю фіктивні дані для тестування в контролі джерел:

1. proj / sql / setup_db.sql
2. proj / sql / dummy_data.sql
3. proj / sql / mssql_specific.sql
4. proj / sql / mysql_specific.sql

А потім я абстрагую всі мої SQL запити, щоб я міг створити весь проект для MySQL, Oracle, MSSQL чи будь-чого іншого.

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

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

Кожна збірка має власну колекцію скриптів SQL, які зберігаються у каталозі $ project \ SQL \ у керуванні джерелами, присвоюють числовий префікс та виконуються в порядку. Таким чином, ми практикуємо нашу процедуру розгортання при кожній збірці.

Залежно від таблиці пошуку, більшість наших значень пошуку також зберігаються в скриптах і запускаються, щоб переконатися, що дані конфігурації є такими, на які ми очікуємо, скажімо, "причини_коди" або "коди країни". Таким чином, ми можемо зробити зміни даних пошуку у розробці, перевірити їх, а потім "просувати" їх через QA та виробництво, замість того, щоб використовувати інструмент для зміни значень пошуку у виробництві, що може бути небезпечно для тривалості.

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

+1 для Liquibase : LiquiBase - це відкритий код (LGPL), незалежна від баз даних бібліотека для відстеження, управління та застосування змін до бази даних. Він побудований на простому приміщенні: всі зміни бази даних (структура та дані) зберігаються в описовій формі на основі XML і перевіряються в контролі джерел. Добре, що зміни DML зберігаються семантично, а не просто розрізняються, щоб ви могли відслідковувати мету змін.

Його можна поєднувати з керуванням версією GIT для кращої взаємодії. Я збираюся налаштувати наше середовище для розробників, щоб спробувати його.

Також ви можете використовувати системи Maven, Ant build для побудови виробничого коду зі скриптів.

Мінусом є те, що LiquiBase не інтегрується в широко поширені SQL IDE, і ви повинні робити основні операції самостійно.

На додаток до цього ви можете використовувати DBUnit для тестування БД - цей інструмент дозволяє використовувати сценарії генерації даних для тестування виробничої середовища з очищенням вперед.

ІМХО:

1. Зберігайте DML у файлах, щоб ви могли їх версії.
2. Автоматизація процесу побудови схеми з управління джерелом.
3. Для цілей тестування розробник може використовувати локальну БД, побудовану з управління джерелом через систему збірки + навантаження даних для тестування зі скриптами, або сценарії DBUnit (від Source Control).
4. LiquiBase дозволяє надати "запустити послідовність" скриптів для дотримання залежностей.
5. Має бути команда DBA, яка перевіряє головний обід із ВСІМ змін перед використанням у виробництві. Я маю на увазі, що вони перевіряють магістраль / відділення від інших DBA, перш ніж вступити в магістральний MASTER. Тож цей майстер завжди послідовний і виробництво готове.

Ми зіткнулися з усіма згаданими проблемами зі зміною коду, злиттям, переписуванням у нашій базі даних про виробництво рахунків. Ця тема чудово підходить для виявлення всього цього.

Задаючи «тизерні запитання», ви, здається, більше зацікавлені в дискусії, ніж чиясь думка остаточних відповідей. Активний (> 2500 членів) список розсилки agileDatabases вирішив багато з цих питань і, на мій досвід, є складним та громадянським форумом для такого роду дискусій.

Я в основному погоджуюся з кожною відповіддю, наданою Ваном . Для отримання більш глибокого розуміння, моєю базовою базою для управління базами даних є серія К. Скотта Аллена (обов'язково читати, IMHO. І думка Джеффа теж здається).

• Об'єкти бази даних завжди може бути відновлений з нуля, запустивши один SQL - файл (який сам по собі може викликати інші файли SQL): Create.sql. Сюди можна включити статичну вставку даних (списки ...).
• Сценарії SQL параметризовані так, що жодна залежна від середовища та / або конфіденційна інформація не зберігається у звичайних файлах.
• Я використовую для користувача пакетний файл для запуску Create.sql: Create.cmd. Його мета головним чином - перевірити наявність попередніх реквізитів (інструменти, змінні середовища ...) та надіслати параметри до сценарію SQL. Він також може завантажувати статичні дані з великого завантаження з файлів CSV для проблем з продуктивністю.
• Зазвичай облікові дані користувачів системи передаються як параметр Create.cmdфайлу.

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

Після введення в дію першої версії бази даних вам знадобляться не тільки складання скриптів (головним чином для розробників), але й сценарії оновлення (засновані на тих самих принципах):

• Повинен бути спосіб отримати версію з бази даних (я використовую збережену процедуру, але так само буде зроблена таблиця).
• Перш ніж випустити нову версію, я створюю Upgrade.sqlфайл (який може викликати інші), який дозволяє оновити версію N-1 до версії N (N - версія, яка випускається). Я зберігаю цей скрипт у папці з назвою N-1.
• У мене є пакетний файл , який робить оновлення: Upgrade.cmd. Він може отримати поточну версію (CV) бази даних за допомогою простого оператора SELECT, запустити Upgrade.sqlскрипт, що зберігається під CVпапкою, і циклічно, поки не буде знайдена папка. Таким чином, ви можете автоматично перейти від, скажімо, N-3 до N.

Проблеми з цим полягають у:

• Важко автоматично порівнювати схеми баз даних, залежно від постачальників баз даних. Це може призвести до неповних скриптів оновлення.
• Кожна зміна виробничого середовища (як правило, DBA для настройки продуктивності) повинна знаходити шлях до управління джерелами. Щоб переконатися в цьому, зазвичай можливе внесення кожної модифікації в базу даних через тригер. Цей журнал скидається після кожного оновлення.
• Однак, в ідеалі, зміни, розпочаті з DBA, повинні бути частиною процесу випуску / оновлення, коли це можливо.

Щодо об’єктів бази даних, які ви хочете мати під контролем джерела? Ну, я б сказав якомога більше, але не більше ;-) Якщо ви хочете створити користувачів з паролями, отримайте їм пароль за замовчуванням (логін / логін, практичний для тестування одиниць) та змусьте пароль змінити ручну операцію . Це багато трапляється з Oracle, де схеми також є користувачами ...

У нас є проект Silverlight з базою даних MSSQL в контролі версій Git. Найпростіший спосіб - переконатися, що ви маєте зменшену базу даних (вміст вмісту), і виконайте повний скид від Fe Visual Studio. Тоді ви можете зробити 'sqlcmd' зі свого сценарію збирання, щоб відтворити базу даних на кожній машині розробників.

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

Я переконаний, що БД має бути частиною контролю джерел і значною мірою частиною процесу збирання. Якщо він знаходиться в контролі джерела, тоді я маю такі ж захисні засоби кодування, коли пишуть збережену процедуру в SQL, як і я при написанні класу в C #. Я роблю це, включаючи каталог сценаріїв БД під моє дерево джерела. Цей каталог скриптів не обов'язково містить один файл для одного об’єкта в базі даних. То був би біль в попці! Я розвиваю в своєму db просто так, як я б у своєму кодовому проекті. Тоді, коли я готовий до реєстрації, я роблю різницю між останньою версією моєї бази даних та поточною, над якою працюю. Для цього я використовую SQL Compare, і він генерує сценарій усіх змін. Потім цей скрипт зберігається в моєму каталозі db_update зі специфічною умовою іменування. частину мого процесу збирання я починаю із нової бази даних, яка потім будується програмно за допомогою скриптів у цьому каталозі. Я написав нестандартне завдання NAnt, яке повторюється через кожен сценарій, виконуючи його вміст на головному db. Очевидно, якщо мені потрібні деякі дані, щоб перейти в db, то у мене також є сценарії для вставки даних. Це також має багато переваг. По-перше, всі мої речі переосмислені. По-друге, кожна збірка - це свіжа збірка, що означає, що в процесі моєї розробки не буде підступних предметів (таких як брудні дані, що викликають дивацтва в системі). По-третє, коли до команди розробників додається новий хлопець, їм просто потрібно отримати останню версію, і їх місцева розробка побудована для них на льоту. По-четверте, я можу запускати тестові випадки (я не називав це "тестовою одиницею"!) У своїй базі даних, оскільки стан бази даних скидається з кожною збіркою (це означає, що я можу перевірити свої сховища, не переживаючи про додавання тестових даних до db).

Це не для всіх.

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

Замість того, щоб вдаватися до аргументів білої вежі, ось рішення, яке дуже добре спрацювало для мене над проблемами реального світу.

Побудова бази даних з нуля може бути зведена як керування сценаріями sql.

DBdeploy - це інструмент, який перевірятиме поточний стан бази даних - наприклад, які сценарії раніше були запущені проти неї, які сценарії доступні для запуску, а отже, які сценарії потрібно запустити.

Потім він зіставить всі необхідні сценарії разом і запустить їх. Потім він записує, які сценарії були запущені.

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

Дивіться хороший вступ тут:

http://code.google.com/p/dbdeploy/wiki/GettingStarted

Ви можете виявити, що Liquibase обробляє багато того, що ви шукаєте.

Кожен розробник повинен мати власну локальну базу даних і використовувати контроль вихідного коду для публікації в команді. Моє рішення тут: http://dbsourcetools.codeplex.com/ Веселіться, - Натане