Контрольный список для обновления схемы базы данных

Question

Необходимость обновления схемы базы данных значительно усложняет установку новой версии программного обеспечения.Каковы наилучшие методы для этого?

Я ищу контрольный список или временную шкалу действий, таких как

• 8:30 завершите работу приложений
• 8:45 изменение схемы
• 9:15 установка новых приложений
• 9:30 перезапустить базу данных

и т.д., показывая, как минимизировать риск и время простоя.Такие вопросы, как

• отказ от обновления, если что-то пойдет не так
• минимизация воздействия на существующие приложения
• "горячие" обновления во время работы базы данных
• продвижение от разработчиков к тестированию на производственных серверах

представляют особый интерес.

Answer 1

У меня большой опыт в этом деле.Мое приложение отличается высокой итеративностью, и изменения схемы происходят часто.Я выпускаю производственный релиз примерно каждые 2-3 недели, для каждого из которых из моего списка FogBugz вычеркивается по 50-100 элементов.Каждый выпуск, который мы делали за последние несколько лет, требовал изменений схемы для поддержки новых функций.

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

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

У меня есть два сценария, которые я запускаю в базе данных, один для изменения схемы, другой для программируемости (процедуры, представления и т.д.).Сценарий изменений закодирован вручную, а сценарий с обработками написан с помощью Powershell.Сценарий изменения запускается, когда все выключено (для этого нужно выбрать время, которое раздражает наименьшее количество пользователей), и запускается команда за командой, вручную, на случай, если что-то пойдет не так.Самая распространенная проблема, с которой я столкнулся, - это добавление уникального ограничения, которое не выполняется из-за дублирования строк.

Готовясь к циклу интеграционного тестирования, я просматриваю свой контрольный список на тестовом сервере, как если бы этот сервер был производственным.Затем, в дополнение к этому, я беру фактическую копию рабочей базы данных (сейчас самое подходящее время заменить ваши резервные копии вне сайта) и запускаю скрипты на восстановленной локальной версии (что также хорошо, потому что доказывает, что моя последняя резервная копия исправна).Здесь я убиваю много зайцев одним выстрелом.

Итак, всего получается 4 базы данных:

1. Дев:все изменения должны быть внесены в сценарий изменений, но никогда в studio.
2. Тест:Здесь происходит интеграционное тестирование
3. Копия продукции:Практика развертывания в последнюю минуту
4. Производство

Вам действительно, очень нужно сделать это правильно, когда вы делаете это на производстве.Отменить изменения схемы очень сложно.

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

Answer 2

Я полагаю, вы рассматривали произведения Скотта Эмблера?http://www.agiledata.org/essays/databaseRefactoring.html

Answer 3

Это тема, о которой я только что говорил на работе.В основном проблема заключается в том, что если миграция базы данных не обрабатывается за вас должным образом вашим фреймворком, например rails и их сценариями миграции, то это остается на ваше усмотрение.

Нынешний способ, которым мы это делаем, имеет очевидные недостатки, и я открыт для других предложений.

1. Создайте дамп схемы со статическими данными, которые необходимо поддерживать в актуальном состоянии и в системе управления версиями.
2. Каждый раз, когда вы выполняете действие по изменению схемы, ИЗМЕНЯЕТЕ, СОЗДАЕТЕ и т.д.сбросьте его в файл и передайте в систему управления версиями.
3. Убедитесь, что вы обновили исходный дамп базы данных sql.
4. При выполнении pushs to live убедитесь, что вы или ваш скрипт применяете sql-файлы к базе данных.
5. Очистите старые файлы sql, находящиеся в системе управления версиями, по мере их устаревания.

Это ни в коем случае не оптимально и на самом деле не предназначено в качестве "резервной" базы данных.Это просто для того, чтобы облегчить жизнь и удержать разработчиков на одной странице.Вероятно, есть что-то классное, что вы могли бы настроить с помощью capistrano в части автоматизации применения sql-файлов к базе данных.

Управление версиями для конкретной базы данных было бы довольно потрясающим.Вероятно, есть что-то, что делает это, и если этого нет, то, вероятно, должно быть.

Answer 4

И если статья Скотта Эмблера разожжет ваш аппетит, я могу порекомендовать его книгу с Прамодом Дж. Садолажем под названием "Рефакторинг баз данных". - http://www.ambysoft.com/books/refactoringDatabases.html

В группе Agile Database group в Yahoo также есть много полезных советов и информации - http://tech.groups .yahoo.com/group/agileDatabases/

Answer 5

Две краткие заметки:

1. Это само собой разумеется...Поэтому я повторю это дважды.
   Убедитесь, что у вас есть действительная резервная копия.
   Убедитесь, что у вас есть действительная резервная копия.

2. @mk.Проверьте Запись Джеффа в блоге о контроле версий базы данных (если вы еще этого не сделали)