Як ви керуєте базами даних при розробці, тестуванні та виробництві?

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

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

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

У нас є тестовий (віртуальний) сервер, на якому працює "випуск кандидатів". Розгортання на тестовому сервері в даний час є дуже ручним процесом, і зазвичай передбачає завантаження останнього SQL з SVN та налаштування його. Також дані на тестовому сервері несумісні. Ви закінчуєте будь-які тестові дані, які останній розробник здійснив на своєму сервері пісочниці.

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

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

Це найбільший бар'єр, який я бачу у просуванні до постійної інтеграції та побудови в один крок. Як ти це вирішуєш?

Подальше запитання: як відстежувати версії бази даних, щоб ви знали, які сценарії потрібно запустити для оновлення певного екземпляра бази даних? Чи згадується таблиця версій на зразок Ланс нижче стандартної процедури?

Дякуємо за посилання на Тарантино. Я не в середовищі .NET, але я знайшов їхню вікі-сторінку DataBaseChangeMangement дуже корисною. Особливо ця презентація Powerpoint (.ppt)

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

У мене є робочий сценарій для цього. Він обробляє ініціалізацію БД, якщо її немає, та запускає сценарії оновлення за необхідності. Також є комутатори для протирання наявної бази даних та імпортування тестових даних з файлу. Це близько 200 рядків, тому я не публікую його (хоча, якщо є інтерес, я можу поставити його на пастібін).

Є пара хороших варіантів. Я б не використовував стратегію "відновлення резервної копії".

1. Сценарій усіх змін вашої схеми, і ваш сервер CI запускає ці сценарії в базі даних. Майте таблицю версій, щоб відслідковувати поточну версію бази даних, і виконувати сценарії лише в тому випадку, якщо вони призначені для нової версії.

2. Використовуйте міграційне рішення. Ці рішення залежать від мови, але для .NET я використовую Migrator.NET. Це дозволяє оновлювати базу даних та рухатися вгору та вниз між версіями. Ваша схема вказана в коді C #.

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

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

Погляньте, як це робить Ruby on Rails.

Спочатку існують так звані файли міграції, які в основному трансформують схему бази даних та дані від версії N до версії N + 1 (або у випадку пониження версії з версії N + 1 до N). База даних має таблицю, в якій розповідається про поточну версію.

Бази даних тестів завжди очищаються перед тестовими одиницями та заповнюються фіксованими даними з файлів.

Книга Бази даних Refactoring: Еволюційний дизайн баз даних може дати вам кілька ідей щодо управління базою даних. Коротка версія читається також на http://martinfowler.com/articles/evodb.html

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

• Назвіть свої бази даних наступним чином - dev_<<db>> , tst_<<db>> , stg_<<db>> , prd_<<db>>(Очевидно, ви ніколи не повинні твердо кодувати імена db
• Таким чином, ви зможете розгорнути навіть різні типи db на одному фізичному сервері (я не рекомендую цього, але вам, можливо, доведеться ... якщо ресурси обмежені)
• Переконайтеся, що ви зможете автоматично переміщувати дані між ними
• Відокремте сценарії створення db від населення = Завжди має бути можливість відтворити db з нуля та заповнити його (зі старої версії db або із зовнішнього джерела даних
• не використовуйте рядки підключення жорсткого коду в коді (навіть не у файлах конфігурації) - використовуйте в конфігураційних файлах шаблони рядків з'єднання, які ви динамічно заповнюєте, кожна переконфігурація application_layer, для якої потрібно перекомпілювати, є BAD
• використовуйте версію бази даних та версію db-об’єктів - якщо ви можете дозволити їй використовувати готові продукти, якщо не розробити щось самостійно
• відстежувати кожну зміну DDL та зберігати її в якійсь таблиці історії ( приклад тут )
• Щоденні резервні копії! Перевірте, наскільки швидко ви змогли би відновити щось втрачене з резервної копії (використовуйте автоматичні скрипти відновлення
• навіть у вашій базі даних DEV і PROD є абсолютно однаковий сценарій створення, у вас виникнуть проблеми з даними, тому дозвольте розробникам створити точну копію prod і пограти з нею (я знаю, я отримаю мінуси для цього, але змінити в мислення та бізнес-процес обійдуться вам набагато дешевше, коли лайно вдарить за фанат - тому змушуйте кодери легально підписувати все, що він робить, але забезпечте це

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

• dbChanges_1.sql
• dbChanges_2.sql
• ...
• dbChanges_n.sql

Це працювало досить добре, поки ми не почали підтримувати дві лінії розвитку: Trunk / Mainline для нової розробки та відділення технічного обслуговування виправлень помилок, короткострокових покращень тощо. На даний момент у нас вже був dbChanges_n + 1.sql у магістралі, тож ми закінчили схему на зразок наступної:

• dbChanges_n.1.sql
• dbChanges_n.2.sql
• ...
• dbChanges_n.3.sql

Знову ж таки, це спрацювало досить добре, поки ми одного разу не підняли голову і побачили 42 дельта-сценарії в основній лінії та 10 у гілці. ARGH!

У ці дні ми просто підтримуємо один дельта-скрипт і даємо версію SVN - тобто ми перезаписуємо сценарій з кожним випуском. І ми ухиляємось від внесення змін у схеми гілок.

Тож я і цим не задоволений. Мені дуже подобається концепція міграцій з Рейлів. Я дуже захопився LiquiBase . Він підтримує концепцію покрокових рефакторингу баз даних. Це варто подивитися, і я незабаром детально розглядаю його. Хтось має з цим досвід? Мені буде дуже цікаво почути про ваші результати.

Ви також можете переглянути інструмент типу SQL Порівняти для скрипту різниці між різними версіями бази даних, що дозволяє швидко мігрувати між версіями

У нас дуже схожа установка з ОП.

Розробники розробляються у ВМ із приватними БД.

[Розробники незабаром почнуть брати участь у приватні філії]

Тестування проводиться на різних машинах (фактично в VM розміщеному на сервері) [Незабаром буде запущений сервер Hudson CI]

Перевірте, завантаживши опорний дамп у db. Застосувати патчі схеми розробників, а потім застосувати патчі даних для розробників

Потім запустіть тести блоку та системи.

Виробництво розгортається на замовників як монтажників.

Що ми робимо:

Ми беремо скидання схеми нашої БД пісочниці. Тоді скидання даних sql. Ми відрізняємо це від попереднього базового рівня. ця пара дельт - оновити n-1 до n.

ми налаштовуємо звалища та дельти.

Отже, щоб встановити версію N CLEAN, ми запускаємо дамп у порожній db. Для наклеювання застосуйте інтервенти, що втручаються.

(Джуха згадав ідею Rail щодо створення таблиці, що записує поточну версію БД, є хорошою, і встановлення оновлень має бути менш загрозливим.)

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

Боюся, я згоден з іншими афішами. Розробникам потрібно скласти сценарій своїх змін.

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

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

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

Ознайомтеся з dbdeploy , там вже доступні інструменти Java та .net, ви можете дотримуватися їхніх стандартів для макетів файлів SQL та таблиці версій схеми та написати свою версію python.

Ми використовуємо командний рядок mysql-diff : він виводить різницю між двома схемами бази даних (з живої БД або скрипту) як сценарій ALTER. mysql-diff виконується при запуску програми, і якщо схема змінена, вона звітує перед розробником. Тому розробникам не потрібно писати ALTER вручну, оновлення схеми відбуваються напівавтоматично.

Якщо ви перебуваєте в середовищі .NET, тоді рішенням буде Tarantino (архівовано) . Він обробляє все це (включаючи, які сценарії sql встановити) у збірці NANT.

Я написав інструмент, який (підключившись до Open DBDiff ) порівнює схеми бази даних та запропонує вам сценарії міграції. Якщо ви внесете зміни, які видаляють або модифікують дані, це призведе до помилки, але надасть пропозицію щодо сценарію (наприклад, коли стовпчик відсутній у новій схемі, він перевірить, чи стовпець був перейменований та створив xx script.sql.suggestion, що містить заяву про перейменування).

http://code.google.com/p/migrationscriptgenerator/ Тільки SQL Server, я боюся :( Це також досить альфа, але це ДУЖЕ низьке тертя (особливо, якщо поєднувати його з Тарантіно або http://code.google .com / p / simplescriptrunner / )

Я використовую це, щоб мати проект SQL-скриптів у вашому .sln. У вас також є локальна база даних db_next, в яку ви вносите свої зміни (використовуючи програму Management Studio або експорт схеми NHibernate або LinqToSql CreateDatabase або щось подібне). Тоді ви виконуєте генерацію migrationscriptgenerator з БД _dev та _next, який створюється. сценарії оновлення SQL для міграції через.

Для бази даних Oracle ми використовуємо інструменти oracle-ddl2svn .

Цей інструмент автоматизував наступний процес

1. для кожної схеми db отримати схему ddls
2. помістити його під версію contol

зміни між екземплярами, вирішеними вручну