Если честно, я не совсем понял вопрос :) Я попробую ответить на вопрос "как в небольшом веб-проекте делать быстрый откат на предыдущие версии".
Предположение 1: В принципе проект умещается на одной физической машине.
Предположение 2: Ваш веб-проект состоит из веб-сервера и БД (по крайней мере, только они обновляются при деплое). Никаких сбоку стоящих MQ, всякого мидл-вара и прочего взаимодействия с другими системами нет.
Мне кажется оптимальным решением сделать следующим образом:
Для откатывания кода достаточно в Jenkins сделать параметризированую сборку, и передавать в эту задачу хэш ревизии, на которую надо откатиться (лично я первым шагом такой сборки запускаю шелл скрипт "hg update -r ${REV_HASH} --clean", но может можно и через плагинчики в гуе настроить). Докер хорош, но он рассчитан на сильно распределенные системы, а в небольшом проекте мне кажется это оверкилл.
С откатыванием БД вопрос сложнее. Во-первых, потому что в любом случае делать "копию" любой базы -- это в той или иной степени лок. Хотя некоторые базы способны очень быстро делать снэпшоты, например mongoDB способна сделать бэкап без остановки и блокирования read/write без потери консистентности (при некоторых условиях, конечно же). Во-вторых, оптимальное решение будет зависеть от размера вашей базы и нагрузки на нее.
Например, если у вас MySQL на 100 мегобайт, то mysqldump, запускающийся Jenkins'ом перед началом деплоя новой версии, будет очень простым и надежным решением (естессно, с сохранением хэша текущей ревизии, чтобы потом одновременно с кодом откатиться).
Если у вас база 20гигов, то можно поднять рядом второй сервачок со слэйв-базой, и лочить ее при дампе тем же mysqldump'ом.
Если со вторым юнитом не хочется морочиться, а система позволяет заблокировать базу на небольшое время, то можно делать снэпшоты с помощью lvm'а, например. (см.
www.lullabot.com/blog/article/mysql-backups-using-...
Из текста, я так понял, что еще интересует вопрос "как в большом проекте делают быстрый откат на предыдущие версии". Я так понимаю, что у "больших дядей" изменить архитектуру БД -- это очень дорогой и трудоемкий процесс. Особенно, если структура обратно не совместима (это же пересчеты всех индексов, огромные объемы информации, ожидание обновления всех реплик и тд). По-поводу деплоя, я так понимаю, у них тоже выбор не очень большой: это либо виртуалки (c докером, или чем-то подобным), либо application platform (либо свои, ли всякие PaaS'ы). Ну, а дальше все равно только одним способом: новые виртуалки/конейнеры включаются, обновляются записи в лоад-балансере, старые виртуалки/конейнеры выключаются.