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

9

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

У нас є 3 середовища для наших баз даних:

Розвиток
Тестування прийняття користувача (UAT)
Виробництво

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

Нещодавно ми почали використовувати Red Gate SQL Source Source для зберігання всіх наших об'єктів (з регулярними комісіями).

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

Будь-які пропозиції щодо процесу?

Дякую

— Джудда
джерело

Схоже, сценарії вашої бази даних не в тому ж контролі джерела, що і ваш "фактичний" код. Чому це? Чи можете ви ставитися до цього як до "вихідного коду" та розміщувати його з окремими гілками?

— Майк М.

В даний час ми зберігаємо лише версію розробки скриптів у контролі джерел і UAT / Production не синхронізуються з активною розробкою. Кожен із скриптів у контролі джерела оновлюється щоразу, коли розробник виконує зобов’язання. Проблема з окремими відділеннями полягає в тому, що ми маємо 1 централізовану базу даних, яку використовують усі (для більших змін ми розгалужуємо окремі бази даних).

1

Ви можете створити гілку для випуску та внести лише зміни, які стосуються випуску. Усі інші зміни повинні бути внесені до багажника. Для цього вам знадобиться дві бази даних розвитку. Чи це буде проблемою?

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

— Judda

5

Міграції

Вгору і вниз, які знаходяться у вашому репо-репортажі та позначені разом із вашим додатком.

Ви навіть можете зробити DIY за допомогою sql квартирних файлів, які змінюють вашу схему та оновлюють версію схеми. Все, що вам потрібно зробити, це:

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

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

— дієтабудда
джерело

Що буде, якщо помилка була знайдена в сценаріях? Ви повернетесь до скрипту sql та оновите його?

— Judda

1

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

— дієтабудда

Дякую за твою допомогу. З першого погляду це виглядає дуже солідним підходом і схожим на нашу стратегію розгалуження.

— Judda

2

Контроль джерела!

Ви не розгортаєте свої бінарні файли розвитку безпосередньо у виробництві, не переходячи через svn / git / p4, то чому б тільки ваші бази даних це робили? Отримайте приватні екземпляри для розробників, щоб перевірити свої локальні зміни, але коли він повинен перейти до db розробки, він повинен пройти через перевірені у DDL файли. Ви навіть можете написати інструменти для автоматичного застосування цих змін DDL (я не знаю жодного існуючого способу зробити це правильно).

Після встановлення обмежень щодо зміни схеми db (Не більше sqlplus -> видавати ddl!) Та мати жорсткий контроль облікового запису (немає доступу DDL для всіх), це має стати більш керованим.

— Subu Sankara Subramanian
джерело

1

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

— Judda

Чому ваш db розвитку повинен бути такого ж розміру, як виробничий db? Вони можуть мати ту саму схему, і ви навіть можете мати спеціальний флот для тестування навантаження з усіма даними, але локальні бази даних розробників можуть бути невеликими. Це також запобігає проблемі з витоком даних і т. Д. - теоретично продажі даних взагалі не повинні впливати на розвиток.

— Subu Sankara Subramanian

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

— Judda

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

— софтведа

0

Виконуючи пропозицію про використання міграції ... можливо, використовуйте O / RM, який підтримує міграцію, як Ruby on Rails та Entity Framework 4.3 Однак проблема обох підходів полягає в тому, що міграція - це все або нічого. Ви не можете (як правило) вибирати, які міграції застосовуються, як ви можете, з точки зору наборів змін.

Інший життєздатний варіант (якщо ви знаходитесь у стеку мікрософт, ви ніколи не згадували про платформу) - керувати своїм SQL за допомогою інструментів бази даних Visual Studio. Він вбудований у рефакторинг (перейменування / видалення стовпців тощо) та робить перевірку моделі. Якщо, наприклад, збережений додаток посилається на стовпець, якого вже немає, він повідомить вас.

— Майкл Браун
джерело