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

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

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

  • 8:30 закрыть приложения
  • 8:45 изменить схему
  • 9:15 установить новые приложения
  • 9:30 restart db

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

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

особенно интересны.

ОТВЕТЫ

Ответ 1

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

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

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

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

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

Так что всего 4 базы данных:

  • Dev: все изменения должны быть внесены в изменение script, никогда со студией.
  • Тест: тестирование интеграции происходит здесь.
  • Копия производства: практика развертывания в последнюю минуту.
  • Продукция

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

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

Ответ 3

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

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

  • Имейте дамп схемы с статическими данными, которые должны быть обновлены и контролироваться версиями.
  • Каждый раз, когда вы выполняете действие смены схемы, ALTER, CREATE и т.д., выгружаете его в файл и бросаете его в управление версиями.
  • Убедитесь, что вы обновили исходный дамп sql db.
  • Когда вы делаете нажатие, убедитесь, что вы или ваш script применяете файлы sql к db.
  • Очистите старые файлы sql, которые находятся в управлении версиями по мере старения.

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

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

Ответ 5

Две быстрые заметки:

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

  • @mk. Проверьте сообщение в блоге Jeff об управлении версией базы данных (если вы еще этого не сделали)