Каждой ветке по хосту c помощью capistrano

[dannote]

Данные в БД можно каждый раз забивать при помощи db/seeds.rb, добавив в deploy.rb для роли demo строчку execute :rake, 'db:seed'. Asset-ы проще собирать локально один раз и синхронизировать rsync-ом. Для этого есть готовый gem.

А Sidekiq и Resque для чего-то кроме отправки электронной почты используете?

[fc_arny]

Да, рассматривался вариант с seed (в том числе и с seedbank'ом), но не устроил нас по одной причине: на проекте сильно накрученный elasticsearch, и для проверки алгоритма(который видоизменялся по требованию заказчика со скоростью света) часто требовался большой объем данных, который хранить в репозитории не хотелось. Также использование одной БД позволило использовать одни и те же uploads-файлы, и как следствие на всех демо-хостах у нас полностью заполнен контент.

capistrano-local-precompile пытался использовать, но тут тоже не все так просто получалось. Если приходиться деплоить на несколько окружений(демо-хосты + staging + production и т.д.), то для каждого окружения создается своя копия ассетов + магифест (это очень заметно, когда статика лежит на поддоменах) и получается, что за спринт накапливается огромное количество ассетов, хотя возможно я что-то делал не так и наверное надо сделать еще один подход и разобраться лучше.

Sidekiq/Resque мы используем в основном для синхронизации данных со сторонними сервисами, которые часто могут отвечать очень долго или быть недоступны.

[AlexLeonov]

Вам осталось только использовать что-то вроде TeamCity, чтобы отслеживать изменения в ветках и инициировать сборку автоматически и вы откроете для себя волшебный мир Continious Integration )))

[fc_arny]

Уже открыли Jenkins, но пока не на полную мощь -) Скорее всего следующим шагом автоматизации будет создание демо-хоста именно на пуш + обновление тикета в JIRA, с плагином это делать удобнее, т.к. он позволяет — sidekiq запустить, переиндексацию или еще что-то, что в коде уже есть в виде rake-тасков или просто модулей.

[AlexLeonov]

Давно хочу описать такую связку. В двух местах уже удачно реализовал. Правда, на PHP, но какая разница?

И да, «демо-хосты» называются по уму «шоты». Терминология предложена разработчиками Badoo, которые были первопроходцами в этом деле.

[fc_arny]

Да, про shot в терминологии Badoo знаком, но еще до той статьи мы делали для PHP аналогичный механизм, но только на fabric, и оперировали понятием демо-хост, но наверное shot — лаконичнее.

[AlexLeonov]

Шот правильнее, потому что есть следующий уровень — билды. Имхо проверка интеграции нескольких задач еще важнее, чем изолированный стенд для каждой задачи.

[leninlin]

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