Во-первых - регулярно вносите небольшие изменения - я работал внештатным разработчиком в нескольких крупных инвестиционных банках в различных системах круглосуточной торговли, и лучшей, самой гладкой моделью развертывания, которую я когда-либо видел, было регулярное (ежемесячное) развертывание с четко определенная стратегия отката каждый раз.
Таким образом, все изменения сводятся к минимуму, ошибки исправляются своевременно, в разработке не наблюдается сползания, и поскольку это происходит так часто, КАЖДЫЙ мотивирован, чтобы процесс развертывания был автоматическим и без сбоев. насколько возможно.
Но неизбежно происходят большие изменения схемы, которые очень затрудняют откат (хотя все еще важно знать - и тестировать - как вы будете откатываться в случае необходимости).
Для этих больших изменений схемы мы разработали модель «преодоления разрыва». То есть мы реализуем слой преобразования базы данных, который будет работать почти в режиме реального времени, обновляя оперативную копию данных схемы new style во второй базе данных на основе текущих данных в текущем развернутая система.
Мы копировали бы это пару раз в день в систему UAT и использовали его в качестве основы для тестирования (следовательно, у тестировщиков всегда есть реалистичный набор данных для тестирования, и слой преобразования тестируется как часть этого).
Таким образом, изменение в базе данных постоянно запущено, и развертывание новой системы - это просто случай:
- заморозить всех
- Отключение слоя преобразования
- Включение нового прикладного уровня
- Переключение пользователей на новый уровень приложений
- Разморозить все
Здесь откат становится чем-то вроде проблемы. Если новая система работает в течение часа, откат к старой системе не является легким. Слой обратного преобразования был бы идеальным, но я не думаю, что у нас когда-либо был кто-то, кто мог бы купить идею потратить время на него.
В конце концов, мы развернемся в самый тихий период и заставим всех согласиться с тем, что откат приведет нас к точке переключения, а все, что пропущено, придется заново набирать вручную. Имейте в виду - это побуждает людей правильно тестировать материал:)
Наконец - как сделать слой преобразования - в некоторых более простых случаях мы использовали триггеры в самой базе данных. Лишь однажды я думаю, что мы внедрили код в предыдущий выпуск, который выполнял «двойные обновления», исходное обновление для текущей системы и еще одно обновление для новой схемы стилей. Намерение состояло в том, чтобы выпустить новую систему в следующем выпуске, но тестирование выявило необходимость настройки базы данных, и на тот момент «уровень преобразования» находился в производстве, так что процесс стал запутанным.
Модель, которую мы чаще всего использовали для слоя преобразования, представляла собой просто еще один серверный процесс, выполняющий наблюдение за базой данных и обновление новой базы данных на основе любых изменений. Это работает хорошо, так как код выполняется за пределами производства, может быть изменен по желанию, не влияя на производственную систему (хорошо - если вы запускаете репликацию производственной базы данных, вы можете, но в противном случае вам следует остерегаться не связывать производство базы данных с некоторыми самоубийственными запросами - просто поместите лучших и добросовестных парней в эту часть кода!)
В любом случае - извините за долгие разговоры - надеюсь, я перевернул эту идею - постоянно выполняйте развертывание вашей базы данных как «живое, работающее» развертывание для второй базы данных, и все, что вам нужно сделать для развертывания новой системы, это разверните прикладной уровень и передайте все на него.