Контрольный список обновлений схемы базы данных
Необходимость обновления схемы базы данных делает установку новой версии программного обеспечения намного сложнее. Каковы наилучшие методы для этого?
Я ищу контрольный список или временные рамки действий, например
- 8:30 закрыть приложения
- 8:45 изменить схему
- 9:15 установить новые приложения
- 9:30 restart db
и т.д., показывая, как минимизировать риск и время простоя. Такие проблемы, как
- поддержка обновления, если все идет не так.
- минимизация воздействия на существующие приложения.
- "горячие" обновления во время работы базы данных
- продвижение с разработчика на тестовые серверы
особенно интересны.
Ответы
Ответ 1
У меня есть большой опыт в этом. Мое приложение очень итеративно, и изменения схемы происходят часто. Я выпускаю продукцию примерно раз в 2-3 недели, из которых 50-100 единиц удалены из моего списка FogBugz для каждого из них. Каждый выпуск, который мы сделали за последние несколько лет, потребовал изменений схемы для поддержки новых функций.
Ключом к этому является практика изменений несколько раз в тестовой среде, прежде чем фактически сделать их на живых серверах.
Я сохраняю файл контрольного списка развертывания, который копируется из шаблона, а затем сильно редактируется для каждой версии с чем-то необычным.
У меня есть два сценария, которые я запускаю в базе данных, один для изменений схемы, один для программируемости (процедуры, представления и т.д.). Изменения script закодированы вручную, а один с procs написан через Powershell. Изменение script запускается, когда все выключено (вам нужно выбрать время, которое раздражает наименьшее количество пользователей для этого), и он запускается командой командой вручную, на всякий случай, если что-то странно. Наиболее распространенной проблемой, с которой я столкнулся, является добавление уникального ограничения, которое не выполняется из-за дублирования строк.
При подготовке к циклу тестирования интеграции я просматриваю свой контрольный список на тестовом сервере, как если бы этот сервер был продуктом. Затем, в дополнение к этому, я получаю фактическую копию производственной базы данных (это подходящее время для замены резервных копий), и я запускаю сценарии на восстановленной локальной версии (что также хорошо, потому что это доказывает мою последняя резервная копия звука). Я убиваю много птиц одним камнем здесь.
Так что всего 4 базы данных:
- Dev: все изменения должны быть внесены в изменение script, никогда со студией.
- Тест: тестирование интеграции происходит здесь.
- Копия производства: практика развертывания в последнюю минуту.
- Продукция
Вы действительно, действительно, должны правильно это понимать, когда делаете это на производстве. Резервирование изменений схемы затруднено.
В том, что касается исправлений, я буду использовать только процедуры исправления, никогда не схемы, если это не очень обособленное изменение и не важно для бизнеса.
Ответ 2
Думаю, вы считали, что читаете Скотта Амблера?
http://www.agiledata.org/essays/databaseRefactoring.html
Ответ 3
Это тема, о которой я только что говорил на работе. В основном проблема заключается в том, что, если миграция базы данных не будет обрабатываться для вас красиво вашей инфраструктурой, например, рельсами и их сценариями миграции, то это остается за вами.
Текущий способ, которым мы это делаем, имеет очевидные недостатки, и я открыт для других предложений.
- Имейте дамп схемы с статическими данными, которые должны быть обновлены и контролироваться версиями.
- Каждый раз, когда вы выполняете действие смены схемы, ALTER, CREATE и т.д., выгружаете его в файл и бросаете его в управление версиями.
- Убедитесь, что вы обновили исходный дамп sql db.
- Когда вы делаете нажатие, убедитесь, что вы или ваш script применяете файлы sql к db.
- Очистите старые файлы sql, которые находятся в управлении версиями по мере старения.
Это отнюдь не оптимально и на самом деле не предназначено как "резервное" db. Это просто сделать толкает, чтобы жить спокойно, и держать разработчиков на одной странице. Возможно, что-то классное, что вы могли бы настроить с помощью capistrano, чтобы автоматизировать применение файлов sql к db.
Контроль конкретной версии Db был бы довольно впечатляющим. Вероятно, есть что-то, что делает это, а если нет, то, вероятно, должно быть.
Ответ 4
И если бумага Скотта Амблера пробудит ваш аппетит, я могу порекомендовать его книгу с Pramod J Sadolage под названием "Рефакторинг баз данных" - http://www.ambysoft.com/books/refactoringDatabases.html
В группе Agile Database в Yahoo есть много полезных советов и информации - http://tech.groups.yahoo.com/group/agileDatabases/
Ответ 5
Две быстрые заметки:
-
Само собой разумеется... Поэтому я скажу это дважды.
Убедитесь, что у вас есть действительная резервная копия.
Убедитесь, что у вас есть действующая резервная копия.
-
@mk. Проверьте сообщение в блоге Jeff об управлении версией базы данных (если вы еще этого не сделали)