Як ви обробляєте розгортання змін бази даних?

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

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

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

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

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

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

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

У SQL Server ви можете зробити знімок безпосередньо перед розгортанням, а потім негайно повернутися до нього, якщо розгортання не вдасться. Це передбачає, що розгортання НЕ відбувається, коли користувачі перебувають у системі (ви не хочете втрачати свої зміни даних). Це найкорисніше під час основного випуску, коли вам, можливо, доведеться зняти всю систему тимчасово, щоб зробити оновлення. Або ви все ще можете зробити знімок і порівняти базу даних між знімком і базою даних, щоб побачити відмінності, якщо вам потрібно відкатати. Такий інструмент, як SQLCompare, може навіть генерувати код, щоб повернутися до структури знімків. Я не знаю, що доступно для інших баз даних.

Зміни в структурі бази даних повинні бути автоматизовані / сценарії та протестовані за допомогою тестового середовища. Зміни вручну є надто ризиковими для виробничого середовища

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

Зміни можна проводити поступово (наприклад, додавання поля) і так перевірятись наживо з меншим ризиком, ніж при виконанні їх за один прохід.

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

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

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