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

Question

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

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

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

и т. Д., Показывающие, как минимизировать риск и время простоя. Такие вопросы, как

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

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

Answer 1

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

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

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

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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

2. @ тк. Прочтите пост в блоге Джеффа по управлению версиями базы данных (если вы этого еще не сделали)

Answer 4

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

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

Answer 5

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

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

1. Иметь дамп схемы со статическими данными, которые необходимо поддерживать в актуальном состоянии и в управлении версиями.
2. Каждый раз, когда вы выполняете действие по изменению схемы, ALTER, CREATE и т. Д. Сбрасывают его в файл и отправляют в систему управления версиями.
3. Убедитесь, что вы обновили исходный дамп sql db.
4. При выполнении pushes to live убедитесь, что вы или ваш скрипт применяете файлы sql к БД.
5. Очистите старые sql-файлы, находящиеся в управлении версиями, по мере старения.

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

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