Each branch on the host using capistrano

I think many people are familiar with the concept of “struggle for staging,” when all the developers at the same time the day before the release want to share their best practices so that the tester checks them as soon as possible and does not have to fix bugs all night , right? Who cares to see how we solve this problem for RoR projects using Capistrano? I ask for a cat.

A bit about tools

We make each new ticket in a separate branch, as git-flow advises . As a task manager / bug tracker, we use JIRA, so the ticket number in JIRA = the name of the branch. We are not using Jenkins CI to its full potential, so far only for deploying code on the staging development version after merging into it for integration testing.

The essence of the problem

I wanted to be able to check each ticket in isolation, and only checked tickets should be taken into the release, and those that contain bugs should be left to the next.

What except Capistrano?

We looked at various options from sharing a work machine with ngrok to SaaS like teatro . The first option turned out to be inconvenient, and the second fell away because not all projects have the opportunity to send to a third party. Therefore, due to the fact that all our RoR projects are deployed using capistrano, it was decided to write a small extension that will deploy the project from a specific branch to its host (for example, jira-123.example.com ).

Process

In short, the development process looks like this: after the ticket is completed, the developer pours it on the demo host, after checking the tester creates a merge request, after which Jenkins pours the future release on staging.

What does capistrano-demo do

All that the developer does during development is pouring code, rolling migrations and launching third-party services (sidekiq, resque, etc.).

This plugin has a number of limitations, the most is that it works only for RoR projects, and only with git.

Configuration

# По умолчанию используется одна БД для всех хостов, если есть деструктивные миграции, 
# то гем дает возможность вручную вписать имя БД
set :demo_db, -> { demo_default_db }
# Хост, на поддомене которого будет создавать демо-хост
set :demo_host, -> { fetch(:application) }
# Команда которую нужно выполнить при рестарте хоста.
# Пример с одно из наших проектов, где требовалось перезагрузить unicorn, nginx и sidekiq:
#      invoke 'unicorn:restart'
#      invoke 'sidekiq:restart'
#      execute :sudo, :service, 'nginx restart'
#      execute :rake, 'cache:clear'
set :demo_restart_cmd, -> { raise 'You must specify "demo_restart_cmd" proc' }
# Папка, в которой лежат шаблоны конфигов, для конкретного окружения
# Пример:
#      File.expand_path("../../../../config/stages/#{fetch(:stage)}/templates", __FILE__)
set :demo_templates_dir, nil
# Хеш, для настройки какой шаблон куда положить после компиляции, шаблоны должны быть .erb
# Пример:
#       set :demo_templates_entries, [
#            {template: '/nginx.conf.erb', file: demo_path.join('config', 'nginx.conf')},
#            {template: '/database.yml.erb', file: demo_path.join('config', 'database.yml')},
#            {template: '/unicorn.rb.erb', file: demo_path.join('config', 'unicorn.rb')},
#            {template: '/settings.local.yml.erb', file: demo_path.join('config', 'settings.local.yml')}]
set :demo_templates_entries, []

How to use

This plugin has only three commands:

• demo: create - create / update a demo host
• demo: restart - reboot
• demo: destroy - Stop processes (configured using before / after) and delete the directory.

To create a demo host you just need to type the cap staging demo: create command from the working directory and that's it. By default it will be offered to pour out the current branch.

Conclusion

At the moment, the biggest problem is the long assembly of assets, you need to force him not to reassemble everything, but only the differential. And also, someone’s migration can break other people's hosts, so we keep a clean base on staging, in this case. There were attempts to make a separate database for each branch, but then it was necessary to create either an empty database or copy. The first option is bad in that you would have to hammer content for testing, and the second - there is no universal tool for copying data for several DBMSs, but in the future we plan to make adapters for SqlLite, MySql and Postgres.

We have laid out our achievements in the public domain , so everyone can read and use them, pull requests are welcome.

PS: In the comments, I am ready to answer your questions, listen to alternative solutions and constructive criticism.