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

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

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

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

Я успішно використовував таку методологію, розроблену в « Контроль версій» та у вашій базі даних :

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

Я часто чую думку про те, "чим це відрізняється від просто утримання скриптів визначення об'єкта під контролем джерела?". Різниця величезна, тому що, коли ви розгортаєте нову версію свого додатка, ви не збираєтеся просто створювати нову базу даних. У більшості разів вашому додатку доведеться оновити існуючу базу даних, включаючи наявну . Це важлива відмінність. Ваші кроки оновлення повинні забезпечити цілісність та узгодженість існуючих даних під час оновлення. Деякі операції є тривіальними в коді (додайте ненульовий стовпець зі значенням за замовчуванням до сценарію визначення об’єкта таблиці, виконано), але вони насправді дуже болючі при фактичному розгортанні (таблиця має 1,5 мільярда рядків, стовпчик "додавання" закінчується простору журналу, якщо це зроблено "простим" способом).

Як це працює з розгалуженням:

• коли гілка створена, вона оснащує поточну версію схеми, скажімо, версія 1.6
• коли команда починає працювати над гілкою, вона додає нову версію, 1.7, а потім починає кодувати крок оновлення з 1.6 до 1.7
• крок оновлення змінюється в міру зміни в галузі. Він завжди запускає скрипт, який оновлюється з v 1.6 до 1.7, але те, що саме роблять ці сценарії, підлягає звичайним ітераціям коду та реєстрація у відділенні
• галузь закінчує розвиток, готується до зворотної інтеграції (щоб бути об'єднаною назад у базову лінію)
  • це робить нову інтеграцію вперед від базової лінії до галузі. Якщо інтеграція не внесе жодних змін до версії схеми, все добре, гілка може змінити інтеграцію як такою, яка є. версія 1.7 стає новою базовою версією.
  • цікавим є той факт, коли інша гілка тим часом інтегрується в базу, і тепер версія базової схеми змінилася, скажімо, на 1,7. У такому випадку наша філія повинна зіткнути версію цільової схеми розгортання до 1.8 та здійснити огляд кроку оновлення, який раніше був від 1.6 до 1.7, щоб побачити, як вона працює в нових умовах, модернізуючи з 1,7 до 1,8. Конфлікти логічної схеми повинні бути вирішені, сценарій може вимагати змін, тестування потрібно зробити. Після завершення гілка може реверсувати інтегруватися в базу. Розгорнута цільова версія продукту тепер стає 1,8.
  • коли інша гілка, що розщедрилася на схему версії 1.6, хоче реверсувати інтеграцію, їй потрібно буде зіткнути її версію схеми до 1.9, протестувати сценарій оновлення з 1.8 до 1.9, тоді вона може інтегруватися назад в базу.

Зауважте, що тут не задіяно жодного інструмента, ніяких магічних схем різного сценарію, не передбачено майстрів і не задіяно натискання правої кнопки натискання-створення-скрипту. Це 100% керований розробником процес, заснований на джерелі (сценарії). Багато хто вважає весь цей процес вичерпним, але він працює. Насправді, як користувач SQL Server, ви вже використовували результати цього процесу у своєму щоденному використанні SQL Server: сам SQL сервер використовує дуже подібний процес оновлення бази даних, і, як ви, напевно, очікуєте, процес розробки продукту широко використовує розгалуження та згадана вами проблема - це справді реальна проблема, яку потрібно вирішити.

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

Хоча моя відповідь може бути не такою тривалою, як Ремус, я вважав це справді хорошим рішенням. У мене це ще не створено у виробництві, тому YMMV *.

Liquibase

По суті це XML-файл, в якому ви вносите зміни в схему до своєї бази даних як нові елементи всередині файлу XML. Наприклад:

<createTable tableName="department">
            <column name="id" type="int">
                <constraints primaryKey="true" nullable="false"/>
            </column>

Він має повністю розроблений синтаксис, так що ви можете майже все, що завгодно, робити з вашою базою даних.

Ви також встановите у своїй установці Liquibase, яку базу даних ви хочете версії. Тоді ви "запускаєте" .xml з доданим виконуваним Java (jar-файлом). Це по суті відтворює ті зміни, визначені у XML у вашій базі даних.

Справжнім шахраєм є те, що ви зберігаєте цей XML-файл у тій самій папці, що і ваш код. Тож у моєму випадку це був Гіт. У мене був цей XML-файл у моїй папці проекту (такий же рівень, як /.git), і тоді, коли я перемикав гілки, XML-файл змінився б у версію цієї гілки, і я запустив би файл .jar, і моя база даних тепер би відображала цю гілку.

* Примітка. Я не закінчив реалізацію, тому що у мене виникли проблеми з підключенням Java до SQL Server. Потрібні деякі драйвери jdbc і такі, і мені не було в настрої. Отже, ваш пробіг може відрізнятися.

Тут, у Red Gate, ми незабаром випускаємо рішення для версії бази даних, яке використовує як SQL Compare, так і SQL Source Control. Для цього використовується підхід до оновлення сценаріїв міграції та штампує базу даних із властивістю розширеної версії, яка відповідає редакції джерела управління.

Ми сподіваємось випустити в середині грудня. Зараз доступний кандидат на випуск. Для отримання додаткової інформації відвідайте:

http://www.red-gate.com/products/sql-development/sql-source-control/entrypage/migration

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

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

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

Я вирішив це, написавши пост-замовлення і гачок після злиття, які можна чудово використовувати з git. Я зберігаю всі свої міграції у вигляді файлів SQL в окремому каталозі та фіксую їх поряд із зміненим кодом PHP. Кожен раз, коли я виконую

git checkout

або а

git merge

git автоматично викликає відповідні міграції вгору та вниз. Дивіться мою реалізацію на Github .