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

Ответ 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 об управлении версией базы данных (если вы еще этого не сделали)